WebSocket需应用层实现断线消息暂存：客户端缓存待发消息至内存或localStorage/IndexedDB，重连后按序重发；服务端需配合消息回溯、ACK机制及离线队列，确保可达性。
WebSocket 本身不提供断线期间的消息暂存功能，需要在应用层手动实现。核心思路是：客户端检测连接状态，断开时将待发送消息缓存到内存或持久化存储（如 localStorage），重连成功后再按序重发。
客户端消息缓存与重发机制
在发送消息前先检查 WebSocket 连接状态，若未就绪则暂存到队列；连接恢复后主动 flush 缓存队列。
- 维护一个待发送消息队列（如
Array或Map），支持入队、出队、清空 - 监听
onopen、onclose、onerror事件，及时更新连接状态标志位（如isConnected = false） - 封装
send()方法：连接正常直接发；否则推入缓存队列，并可选设置重试次数或超时丢弃 - 重连成功后遍历队列逐条发送，建议加简单防抖或间隔（如
setTimeout(..., 100)），避免服务端压力突增
本地持久化保障离线可靠性
仅靠内存缓存无法应对页面刷新或崩溃，需结合 localStorage 或 IndexedDB 持久保存待发消息。
- 每次入队时同步写入
localStorage（注意序列化和大小限制，单条建议 ≤ 2MB） - 页面加载时读取并还原缓存队列，再尝试重连；重发成功后及时从 storage 中移除对应项
- 为每条缓存消息添加唯一 ID 和时间戳，便于去重和过期清理（例如超过 24 小时自动丢弃）
- 若消息敏感或体积大，改用 IndexedDB 存储更稳妥，支持事务与二进制数据
服务端配合提升消息可达性
纯客户端缓存不能保证最终送达，服务端需支持“消息回溯”或“离线消息投递”，才能真正解决断线丢失问题。
立即学习“Java免费学习笔记（深入）”；
- 客户端连接时带上 lastSeenId 或 timestamp，服务端比对后补推未确认消息
- 关键业务消息启用 ACK 机制：客户端收到后主动回执，服务端收到才删除缓存；超时未回执则重推
- 服务端维护每个 client 的离线消息队列（如 Redis List），连接恢复时主动推送
- 避免重复消费：消息 ID 全局唯一 + 客户端幂等处理（例如根据 ID 去重渲染）
简化场景下的轻量实现示例
适用于非强一致性要求的场景（如聊天室状态广播、实时通知），无需复杂服务端改造。
- 用
sessionStorage缓存本次会话内未发出的消息（关闭标签页即清空） - 利用
beforeunload事件做最后尝试发送，失败则降级为本地提示“已离线，稍后重试” - 对非关键消息设置 TTL（如 5 分钟），过期自动丢弃，防止堆积
- UI 层显示“正在重连…”、“已缓存 X 条”，增强用户感知和信任感
