websocket在线测试工具

我把一个WebSocket地址填进浏览器里的测试在线测试工具，点“连接”，工具屏幕上的测试状态从“未连接”跳到“已连接”，只花了0.3秒。工具这个工具长得很朴素，测试一个输入框，工具一个连接按钮，测试下方一块黑底绿字的工具日志区域。可就是测试这简单的界面，解决了我一整个下午的工具抓狂。

事情是测试这样的。我本地跑着一个实时推送服务，工具代码逻辑看起来没问题，测试可前端就是工具收不到消息。调试器里看网络请求，测试WebSocket那一栏一直是pending状态。这时候我脑子里闪过一个念头——会不会是服务端推送时机不对？但前端代码已经改了好几轮，实在不想再动浏览器那一堆断点。

我打开在线测试工具，输入ws://localhost:8080/ws，点连接。日志区立刻打出两行字：
[已连接] 握手成功，协议版本13
[服务器] 欢迎加入直播间，当前在线人数1
然后我等了五秒，什么也没发生。服务器没推任何消息。我又手动在工具的消息框里输入ping，点发送，日志区显示[已发送] ping，紧接着服务器回了一条pong。这证明服务器活着，连接也正常，双向通信都没问题。

那问题出在哪？我盯着日志看了半天，忽然意识到——工具上有个“自动回复”开关。默认是关的。我打开它，设置成自动回复ack，再点连接。这次日志区热闹了，服务器每隔两秒推一条heartbeat，工具自动回ack，服务器再推next……整个过程清晰得像在看心电图。

原来我的服务端代码里写了个心跳检测逻辑，要求客户端在收到heartbeat后必须回ack，否则断开连接。而我的前端代码里，只处理了业务消息，完全没处理心跳包。所以连接建立了，但很快被服务端判定为“死连接”踢掉。前端看到的pending，其实是连接被反复断开重连的结果。

这类在线工具的好处就在于，它把WebSocket协议里那些看不见的细节全摊开了。你不需要写一行代码，就能验证服务器是否按预期推送、消息格式是否正确、心跳机制是否正常。比用浏览器DevTools看网络面板直观得多——后者只告诉你“连接建立”，不告诉你“连接为什么被断开”。

当然工具也有局限。它没法模拟浏览器那样的复杂场景，比如跨域限制、cookie携带、子协议协商。但就调试协议本身而言，它比任何IDE插件都来得干脆。我现在养成了个习惯：任何WebSocket接口，先拿在线工具跑一遍握手和基本消息收发，确认服务端没有基础性错误，再动前端代码。

那次调试最后只花了二十分钟。找到问题后，我在前端加了个两行代码的心跳响应，消息立刻像流水一样刷出来了。工具关掉之前，我看了眼日志区最后一条记录——[连接已关闭] 客户端主动断开。干净利落，就像它帮我理清的那个问题一样。