websocket消息必然丢失，因原生协议仅提供tcp裸通道、无ack与重试机制；必须由应用层通过唯一id+持久化存储+ack闭环+指数退避重试+客户端状态兜底来保障可靠性。
WebSocket 消息发送失败后，不能靠重试循环硬扛，必须配合状态可追溯、过程可验证的机制。原生 WebSocket 只保障 TCP 层字节流传输，不承诺消息送达、处理成功或客户端渲染完成——应用层不补全，就必然丢。
消息唯一标识与持久化落库
每条关键消息在发出前，必须携带全局唯一 ID（如 UUID 或带时间戳的业务序列号），并同步写入持久化存储（Redis、数据库或 Kafka）。这步不是可选项：若发送方进程崩溃或重启，未确认的消息将彻底丢失。
- ID 是后续 ACK 匹配、去重、归档的唯一依据
- 元数据需至少包含：消息体、ID、发送时间、当前重试次数、TTL（如 5 分钟）
- 避免用内存 Map 存待确认消息——它扛不住服务重启
ACK 驱动的确认闭环
接收方处理完消息后，必须主动返回含对应 ID 的 ACK 帧；发送方收到 ACK 后，才从持久化存储中安全删除该记录。没有 ACK，就不算送达。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 不要等服务端“发完即了事”，ACK 必须由接收方显式触发
- 客户端也要实现 ACK 发送逻辑，不能只依赖服务端广播
- 服务端收到重复 ID 的 ACK 应静默忽略，保证幂等
智能重试调度与退避策略
后台定时任务（如 Quartz 或 Redis ZSET 扫描）持续检查超时未 ACK 的消息。重试不是线性轮询，而是按指数退避 + 随机抖动执行：
- 首次重试延迟 1 秒，第二次 2 秒，第三次 4 秒……上限设为 60 秒
- 每次延迟乘以 0.8~1.2 的随机系数，防“惊群”
- 单条消息最大重试 5 次，超限转入死信队列并告警
客户端状态兜底与安全发送
前端调用 send() 前，必须检查 socket.readyState === WebSocket.OPEN。封装 safeSend 函数是基本操作，否则网络抖动后 readyState 变为 CLOSING 或 CLOSED，send() 会静默失败。
- 切后台、关标签页、设备休眠都会让连接失效，onmessage 不会触发
- 搭配心跳保活（每 30 秒 ping），及时发现“假连”状态
- onclose 中根据 event.code 判断：1006 / 1011 触发重连，1000 则不重连
