WebSocket离线重连需客户端主动检测与恢复：通过定时PING/PONG心跳、指数退避加随机抖动重连、序列号同步机制防消息丢失，并严格区分连接状态。
WebSocket 本身在离线环境下无法工作——连接断开后，send() 会直接抛出 InvalidStateError，onclose 不一定触发，readyState 可能卡在 CONNECTING 或 OPEN（“假在线”）。所谓“离线重连”，本质是客户端主动检测 + 主动恢复，不是协议自带能力。
为什么 onclose / onerror 经常不触发
真实弱网或离线场景下，TCP 连接可能处于半开（half-open）状态：客户端已断网，但服务端未收到 FIN 包；路由器 NAT 表超时、防火墙静默丢包、手机切后台被系统挂起网络——这些都不会触发标准 WebSocket 事件。
-
onclose只在收到服务端 Close Frame 或本地显式调用close()时可靠触发 -
onerror并非网络错误兜底机制，很多断连根本不会派发该事件 - 仅靠事件监听 = 放弃对“静默断网”的防御能力
心跳检测必须由客户端主动发起
服务端单向 ping 不够——客户端离线时收不到，也无法反馈。真正可用的心跳是「客户端定时 send("PING") + 服务端响应 "PONG"」，再配合客户端超时判定。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 客户端每
30000ms 发一次"PING"（需确保服务端能识别并 echo 或单独处理） - 维护一个
lastPongTime时间戳，每次收到"PONG"就更新 - 用
setInterval检查：if (Date.now() - lastPongTime > 60000) { disconnect(); attemptReconnect(); } - 注意：不能只依赖
socket.ping()（底层 TCP keepalive），浏览器不暴露该 API，且不可控
指数退避重连必须加随机抖动
纯 1s → 2s → 4s → 8s 的退避，在服务端重启等集群级故障时，所有客户端会在同一毫秒发起重连请求，形成雪崩。
- 每次重试前生成随机偏移：
const jitter = Math.random() * 1000; - 实际延迟 =
Math.min(baseInterval * 2 ** attempt, maxInterval) + jitter - 初始
baseInterval建议设为1000，maxInterval不超过30000（避免用户等待过久） - 重连前清空旧 socket 引用，并调用
socket.close(4999, "reconnecting")避免资源泄漏
重连时如何避免消息丢失
重连成功 ≠ 消息续传。必须和服务端约定序列号（seq）与游标（cursor）机制：
- 客户端发送每条业务消息时附带自增
seq，并本地缓存未 ack 的消息（如用Map存seq → message） - 连接重建后，先发
{"type":"sync","lastSeq":123}，服务端比对并补推124+的消息 - 服务端返回补发消息时，必须包含
ack: true和对应seq，客户端收到后从缓存中清除 - 注意：不要在重连成功回调里立刻发业务消息——要等
sync完成且收到首个ack后再恢复发送队列
最易被忽略的点：客户端必须区分「连接未建立」和「连接已建立但无心跳响应」两种状态。前者走完整重连流程，后者只需重置心跳计时器并尝试发 PING；混淆二者会导致频繁误判离线，或错过真实断连。保活不是心跳+重连的拼凑，而是状态机驱动的闭环——每个环节都要有明确入口、出口和兜底动作。
