WebSocket 闪断需建立可感知、可抑制、可恢复的闭环机制：主动心跳探测（20–30秒ping/5秒超时pong）、指数退避+随机抖动重连（上限10次）、清理旧连接与定时器、动态更新凭证并严格对齐服务端保活配置。
WebSocket 连接中断后，不能靠“一断就重连”来应付，关键在于建立一套可感知、可抑制、可恢复的闭环机制。单纯监听 onclose 并立刻 new WebSocket()，往往失效——因为很多闪断根本不会触发该事件，连接状态仍显示为 OPEN，但消息已无法收发。
主动心跳探测，及时发现“假连接”
闪断常表现为：readyState === 1 却收不到消息，onclose 延迟数秒甚至不触发。这说明底层 TCP 已断，应用层却浑然不知。必须用业务层心跳主动验证：
- 连接建立后，每 20–30 秒 发送一次
{"type":"ping"}（间隔需小于链路中最短空闲超时，如 Nginx 的proxy_read_timeout或移动网关的 30s 限制） - 同时启动响应计时器（建议 5 秒内未收到 {"type":"pong"}），立即调用
ws.close(4999, "no_pong")主动断开 - 避免使用浏览器原生 ping/pong 帧——JS API 不暴露发送接口，只能用业务消息模拟
指数退避 + 随机抖动，防重连风暴
固定间隔或立即重连容易引发雪崩：大量客户端在同一时刻重连，瞬间打满服务端连接队列。应采用带扰动的退避策略：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 基础延迟公式：
delay = Math.min(1000 * Math.pow(2, retryCount), 30000)（从 1s 起，上限 30s） - 叠加 ±30% 随机抖动：
delay += Math.random() * delay * 0.3 - 总重试次数 ≤ 10 次；超过后暂停自动重连，改由用户手动刷新或提示“网络异常，请检查”
-
retryCount必须在onopen中清零，否则会沿用旧计数导致过早达到上限
清理旧连接与状态竞争
反复抖动时，若不清理残留实例，极易出现多个 WebSocket 并发、消息重复、token 冲突、内存泄漏：
- 用唯一全局引用（如
wsRef）管理当前连接，每次新建前先执行wsRef?.close()并置空 - 设
isReconnecting标志位，在onclose中判断是否已在重连中，防止多次触发重连逻辑 - 重连前务必清除上一轮的心跳定时器（
clearInterval(pingInterval)）、超时计时器（clearTimeout(heartbeatTimeout)）及所有事件监听器
动态更新凭证，匹配服务端保活配置
重连 URL 若含 token，必须在每次重连前重新获取——旧 token 很可能已在上次断连期间过期，直接复用会导致循环失败；同时确保客户端心跳间隔、超时阈值与服务端保活策略（如 keepalive timeout、ping interval）严格对齐。生产环境中，80% 的闪断问题根源不在前端代码，而在于心跳和服务端配置错配。
