WebSocket原生不保证业务消息100%送达，因TCP仅确保字节流到达内核缓冲区，无法覆盖客户端崩溃、服务端重启、onmessage未执行完等业务层丢失场景；必须在应用层实现ID+ACK+超时重发闭环，并配合心跳、幂等去重与断线补发机制。
WebSocket 本身不提供应用层的重传和确认机制，它只依赖 TCP 的底层可靠性（有序、无丢包），但无法保证消息被业务代码真正处理。要实现端到端的可靠通信，必须在应用层补充 ACK、超时、重传、去重等逻辑。
为什么 WebSocket 需要额外加可靠性保障
TCP 确保数据到达对方内核缓冲区，但以下情况仍会导致“业务层面丢失”：
- 连接断开瞬间，消息已发到 TCP 层但未被应用读取
- 客户端页面刷新或崩溃，onmessage 回调没执行完
- 服务端异常重启，内存中待处理消息丢失
- 接收方处理缓慢或阻塞，消息积压后被丢弃（如 WebSocket 缓冲区满）
核心可靠性组件：ACK + ID + 超时重传
这是最轻量也最通用的方案，适用于聊天、指令控制、状态同步等场景：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
每条消息带唯一 ID（如
msg_1724508201234_0），服务端与客户端各自维护 ID 映射 - 发送方记录待确认消息：存入 Map 或队列，附带发送时间、重试次数、定时器
-
接收方处理完后主动回 ACK：格式如
{"type":"ack","originalId":"msg_xxx"} - 发送方收到 ACK 后清除本地记录；超时（如 3–5 秒）未收到则重发，最多重试 3 次
服务端如何知道客户端收到了
不能靠 onmessage 触发就认为“已确认”，而要明确区分两个动作：
- 收到（receipt）：WebSocket 底层触发 message 事件 → 表示数据已抵达 JS 引擎
- 确认（acknowledgement）：业务逻辑处理完毕（如存库、广播、更新 UI）→ 主动 send 一条 ACK 消息
服务端只有收到这条 ACK，才能安全地从待确认队列中移除该消息，并视作“端到端送达成功”。
配合心跳与重连提升整体健壮性
单靠 ACK 不足以应对网络抖动或假死连接：
-
心跳保活：每 20–30 秒发一次 ping 帧（或自定义
{"type":"ping"}），对方回 pong，超时未响应则主动 close 并重连 - 断线重连策略：指数退避（如 1s → 2s → 4s → 8s），避免雪崩式重连；重连成功后可请求“未确认消息补推”或“离线消息拉取”
- 消息去重：服务端收到重复 ID 的消息（因重传导致），需根据 ID 幂等判重，跳过二次处理
