对账时服务端记了 1200 条已发送，客户端只收到 900 条，缺的 300 条服务端 send 返回值都是 true，没有一条报错。日志里能对上时间点，这种反而好排。
send 只表示数据写进了本地缓冲，不代表对端收到，链路断了缓冲区里的内容直接丢。没有应用层 ack，服务端无从判断哪些需要重发。这一点先确认清楚，后面就不用反复试。
ws.send(JSON.stringify({ seq, payload }));
// 客户端收到后: ws.send(JSON.stringify({ type: 'ack', seq }));
这次卡住的地方就在「消息确认机制」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
报错里带路径的，先去看那个路径在不在、权限对不对。
处理上按这个顺序：每条消息带 seq 客户端收到后回 ack；服务端维护未确认列表 超过 5 秒重发 三次后断开；重连时客户端上报最大 seq 服务端补发之后的；监控未确认条数 持续大于 0 就告警。
结果对不对很好判断，断网 10 秒再恢复 客户端条数和服务端完全一致 缺口为 0。