WebSocket如何实现断线后的消息补发离线消息队列设计方法【教程】-js教程-PHP中文网

websocket断线消息补发必须由应用层实现，因浏览器不自动重发bufferedamount中未发出的消息；需用localstorage持久化待发队列、重连后先拉取离线消息再按序重发，并要求服务端配合即时ack、幂等校验与ttl清理。

websocket如何实现断线后的消息补发离线消息队列设计方法【教程】

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}，没有就跳过（说明已成功）