WebSocket断线消息补发必须由应用层实现，因浏览器不自动重发bufferedAmount中未发出的消息；需用localStorage持久化待发队列、重连后先拉取离线消息再按序重发，并要求服务端配合即时ACK、幂等校验与TTL清理。
WebSocket 本身不提供断线消息补发能力，所有补发逻辑必须由应用层自己实现。靠 ws.send() 直接发、靠重连自动恢复，一定会丢消息。
为什么 onclose 触发时消息已经“消失”了
浏览器的 WebSocket 对象在连接断开后，未发出的消息不会排队等待，也不会抛错——它们就卡在 socket.bufferedAmount 里，直到页面刷新或实例销毁。你看到的“发送成功”，只是进了浏览器输出缓冲区，不代表服务端收到了。
-
bufferedAmount > 0是唯一能判断“有消息没真发出去”的信号，必须在onclose或onerror中立刻检查 - 不要依赖
ws.readyState === 1判断可发，断连瞬间它可能还是 1，但后续 send 就会静默失败 - 服务端如果没收到，也不会通知前端；前端若不主动记账，这条消息就彻底不可追溯
本地待发队列怎么建才不丢不乱
内存队列（如 pendingQueue = []）只够应付毫秒级断连。页面刷新、APP 切后台、用户手动关闭标签页，都会清空它。真正可用的队列必须落盘。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 高优消息存
localStorage：每条用JSON.stringify({ messageId, payload, timestamp })存，key 可设为pending:${messageId} - 单条别超 1MB，否则写入可能失败；写入前先
try { JSON.stringify(...) } catch校验 - 避免用时间戳拼 ID，改用
crypto.randomUUID()生成messageId，防止服务端去重失效 - 页面加载时遍历
localStorage所有pending:key，重建队列；注意过滤已过期（如 24 小时）的条目
重连后先拉离线消息，再发本地队列
顺序错了，消息就会倒序。比如用户 A 在断连期间发了“你好”，服务端存了离线消息；而用户 B 重连后立刻把本地缓存的“稍等”发出去——结果对方先收到“稍等”，后收到“你好”。
- 重连成功（
onopen）后第一件事：发同步请求{ type: "fetch_offline", lastSeq: 12345 }，其中lastSeq是客户端本地已处理的最大序列号 - 服务端返回离线消息列表，客户端逐条处理并立即响应 ACK，确保服务端标记为“已送达”
- 离线消息全部 ACK 完毕，再开始从本地待发队列中按原始顺序重发
- 每条重发前查一遍
localStorage是否还有对应pending:${id}，没有就跳过（说明已成功）
服务端必须配合的三件事
前端做得再细，服务端不配合，补发就是单机游戏。最常被忽略的是 ACK 延迟和幂等校验。
- 收到任意业务消息，立刻返回
{"type":"ack","messageId":"xxx"}，不要等 DB 写完；延迟 ACK 会导致前端反复重发 - 所有写操作前，先用
messageId查 Redis/DB，已存在就直接返回 ACK，不执行业务逻辑 - 离线消息必须带 TTL（建议 7 天），key 设计为
offline:${userId}:${messageId}，避免全量扫描
真正难的不是写队列或发重试，而是让前后端对“这条消息到底算不算送达”达成一致。只要有一端没按约定走流程，补发就会漏、会重、会乱序。所以别急着堆代码，先对齐 message ID 生成规则、ACK 返回时机、离线消息 TTL 和清理策略。
