websocket本地测试工具

去年调试一个实时聊天功能，地测前后端联调时被浏览器控制台的试工报错折磨了整整三天。问题出在服务端推送消息的地测格式上，但浏览器自带的试工开发者工具只能看网络请求，没法手动模拟WebSocket连接。地测最后翻出老旧的试工Postman，发现它对WebSocket的地测支持也仅限于发个请求，收消息还是试工得靠console.log硬看。

后来我换了个思路，地测直接在本地起一个Node.js脚本，试工用ws库开个临时服务端，地测再用浏览器页面连上去。试工这法子能跑通，地测但每次改完代码要重启进程，试工消息多了还得自己拼JSON，地测麻烦得很。直到同事甩给我一个开源小工具——websocat，命令行里敲两下就能建立连接，还能把收到的消息实时打印出来。那一刻我才意识到，本地测WebSocket，工具选对了能省一半时间。

现在我的工作流基本固定成三件套。第一件是websocat，专治“我就想看看服务端推了啥”。比如你写了个股票行情推送接口，直接在终端跑websocat ws://localhost:8080，服务端一推数据，终端立马刷出来。要是嫌输出太乱，还能用-n参数关掉交互模式，纯当监听器用。

第二件是浏览器插件Smart WebSocket Client，适合需要带header或者cookie的场景。有回测一个需要鉴权的推送服务，浏览器里登录后拿到token，插件里填上请求头，再连上ws地址，消息收发都带时间戳，比纯命令行直观多了。它的界面简陋得像十年前写的，但胜在能保存历史记录，换台电脑重新配置时不用翻聊天记录找参数。

第三件才是真正压轴的东西——我自己写的那个二十来行的Python脚本。别笑，它解决的是websocat和浏览器插件都搞不定的场景：需要模拟多客户端并发连接。比如测一个群聊系统，得同时开五个连接互相发消息。websocat得开五个终端窗口，插件更惨，同一时间只能维持一个连接。但Python里用websockets库起五个协程，每个协程连上后随机发消息，跑一轮下来，服务端有没有丢消息、有没有乱序，一目了然。

有人会问，直接上JMeter或者Postman这种重型工具不行吗？行，但杀鸡用牛刀。JMeter配置WebSocket Sampler得先装插件，Postman的WebSocket请求格式又跟原生协议有细微差别，有时候服务端解析不了。本地调试讲究的是快，打开就能用，报错能直指问题核心。那些大而全的工具，更适合压测或者做接口文档，日常联调反而被配置流程拖慢节奏。

还有一个容易被忽略的点：本地测试工具要能模拟异常情况。websocat有个--ping-interval参数，能每隔几秒发一次心跳包，专门用来测服务端有没有做断线重连。浏览器插件虽然能看消息内容，但没法模拟半开连接这种网络层故障。这时候还得靠命令行工具，直接Ctrl+C掐断连接，看服务端日志里有没有记录到异常断开。

说这么多，其实核心就一句话：选WebSocket测试工具，别追求功能全，要看它合不合你的调试场景。像我平时主要写业务逻辑，websocat加插件就够了。要是做框架开发或者协议分析，那可能还得上Wireshark抓包。工具是死的，调试思路是活的，多试几种组合，总能找到最顺手的那套。

最后提个醒，本地测WebSocket时最好把服务端的日志级别调到DEBUG，不然光看客户端收到的消息，很难定位是发送端拼错了数据，还是接收端解析出了问题。别问我怎么知道的——上周刚因为少打了个引号，排查了俩小时。