WebSocket消息丢失本质是应用层状态管理缺失：onmessage仅表示数据抵达JS引擎，不保证业务执行完成；需在业务完成点（如写入本地存储后）显式发ACK；ws.bufferedAmount可预警客户端拥塞；可靠补全离线消息须依赖服务端持久化（如Redis Sorted Set）与带鉴权的sync/ack机制。
WebSocket消息丢失不是TCP层问题，而是应用层缺乏状态管理导致的——靠重连或换库解决不了根本问题。
为什么onmessage收到消息后仍算“丢失”
浏览器触发onmessage只代表数据已抵达 JS 引擎，不代表业务逻辑已执行完毕。常见断点包括：
- 消息解析失败（如 JSON 格式错误）但未抛异常，后续逻辑跳过
- UI 渲染前标签页被关闭，
console.log都来不及输出 - 异步操作未 await（如
await saveToIndexedDB(msg)被漏掉） - Vue/React 状态更新被批量合并，中间态丢失
这类“伪接收”在监控里表现为 100% 消息到达率，但用户反馈“没看到”。关键不是加日志，而是在业务完成点显式标记“已处理”，比如写入本地存储后发回 ACK。
ws.bufferedAmount 是唯一能提前预警的指标
它反映浏览器 WebSocket 对象内部待发送队列长度（单位：字节），不是网络缓冲区，也不是服务器接收窗口。值持续 > 0 说明客户端出口已拥塞：
- 值突增至几十 KB 且不回落 → 客户端卡顿或渲染阻塞（如长任务占主线程）
- 值缓慢爬升至几 MB → 服务端推送频率远超客户端处理能力
- 值归零后突然跳变 → 可能是连接重置后重建，旧缓冲被清空
不要轮询检查，用 setInterval 每秒读一次即可。超过阈值（如 128KB）应主动暂停接收新消息，或降级为轮询拉取。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
重连时如何补全离线期间的消息
靠客户端自己记 lastMessageId 或 timestamp 不可靠——时间不同步、ID 生成冲突、本地存储被清除都会导致漏补。必须依赖服务端持久化：
- 所有需可靠投递的消息，写入 Redis Sorted Set，key 为
user:{uid}:inbox，score 为毫秒时间戳 - 客户端重连后发送
{"cmd":"sync","since":1716543210000}，服务端返回该时间之后全部消息 - 服务端响应后，客户端逐条处理并发送
{"cmd":"ack","mid":"msg_abc123"}，服务端从 Sorted Set 中ZREM - 若某条消息 ACK 失败，下次 sync 会再次包含它，靠客户端去重（用 Map 缓存已处理
mid）
这个流程里，sync 请求必须带鉴权 token，不能仅靠 Cookie —— 防止恶意遍历用户 inbox。
ACK 机制里最容易被忽略的细节
多数人实现 ACK 时只做“发了就等”，却忽略了三个现实约束：
-
WebSocket.send()是异步的，调用成功不等于数据已发出。真正可靠的 ACK 触发点是onopen后首次send()的回调（需用ws.addEventListener('message', ...)捕获） - 服务端收到 ACK 后，不能立刻删消息。要等数据库事务提交完成再删，否则崩溃会导致重复投递
- 客户端重试时，
messageId必须复用原始 ID，不能每次重发都生成新 ID —— 否则服务端无法识别这是重传还是新消息
最终效果不是“每条消息必达”，而是“每条消息的状态可追溯”。丢消息不可怕，可怕的是不知道它到底卡在哪一环。
