websocket消息可靠性需前端构建应用层机制：强制消息入队+唯一id标记、indexeddb持久化存储、心跳检测与指数退避重连、ack驱动确认清理、状态可视化与安全降级。
WebSocket 本身不提供消息可靠性保障，前端必须自己构建一套应用层机制来实现“发出去 = 对方处理了”。可靠的消息队列与离线缓存重发不是加个定时器或存 localStorage 就能搞定的事，关键在于状态可追踪、存储可持久、重发可控制、体验可感知。
发送前强制入队 + 唯一 ID 标记
所有业务消息不能直调 ws.send()，必须先走统一入口封装：
- 每条消息生成唯一 ID（推荐
crypto.randomUUID()或Date.now() + Math.random()组合），附带时间戳、类型、重试次数、过期时间（如 24 小时） - 入队即写入 IndexedDB（比 localStorage 更可靠，支持事务和大容量），结构示例：
{ id, payload, status: 'pending', createdAt, retryCount } - 连接就绪时才真正发送；若未就绪，自动暂存并标记为 “waiting”
连接状态管理 + 智能重连调度
仅监听 onclose 不够，真实网络中断往往悄无声息：
- 建立应用层心跳：每 15–30 秒发一次
{"type":"ping"}，超时（如 5 秒未收到pong）即判定“疑似断连” - 断连后暂停新消息入队，启动指数退避重连（1s → 2s → 4s → 最大 30s），避免雪崩式重连请求
- 重连成功后，从 IndexedDB 中读取所有
status === 'pending'的消息，按时间顺序逐条重发，并加 100ms 间隔防压
服务端 ACK 驱动客户端确认清理
客户端不能靠“发出去了”就认为成功，必须等服务端回执才能删缓存：
- 每条业务消息发出后，启动一个定时器（如 10 秒超时），等待服务端返回
{"type":"ack","id":"xxx"} - 收到 ACK 后，立即从 IndexedDB 中删除对应记录；超时未收则增加
retryCount并重新入队 - 敏感操作（如支付、密码修改）可额外拦截：检测到离线状态时直接禁用按钮，提示“请联网操作”
用户体验与安全边界控制
再完善的机制也要让用户看得见、信得过：
- 界面上显示实时状态：“已缓存 3 条”、“正在重连…”、“同步完成，2 条已送达”
- 设置队列硬限制：IndexedDB 中最多存 100 条待发消息；单条存活不超过 24 小时，到期自动归档或丢弃
- 页面刷新不丢数据：初始化时优先从 IndexedDB 恢复队列，再触发重连逻辑
- 避免在离线状态下执行强依赖实时性的逻辑（如协作光标、音视频信令），提前降级为只读模式
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
