websocket闪断需建立感知-抑制-恢复闭环机制，须主动心跳探测、指数退避+抖动重连、清理旧连接、动态更新凭证，并确保心跳与服务端保活配置匹配。
WebSocket连接闪断不是“修一下就能好”的问题，而是必须在客户端建立可感知、可抑制、可恢复的闭环机制。单纯监听 onclose 并立刻重连，大概率会让问题更糟。
闪断的本质是“假连接”未被及时发现
闪断常表现为：消息突然停止收发，但 ws.readyState === 1 仍为 OPEN；onclose 延迟数秒甚至数十秒才触发；服务端日志里没有对应关闭记录。这说明底层 TCP 连接已断裂，但应用层尚未察觉。
- 典型诱因包括：NAT 超时（家用路由器常见）、手机切后台被系统挂起、代理/防火墙静默丢包
- 只依赖
onopen/onclose事件等于靠天吃饭——这些事件在闪断场景下严重滞后或根本不触发 - 必须引入主动心跳探测：每 30s 发一次
{"type":"ping"}，并配超时判定逻辑（如 5s 内未收到pong就ws.close(4999, "no_pong")）
重连不能用固定间隔，必须加抖动+退避
网络抖动恢复时，若所有客户端在同一时刻发起重连（比如都设了 3s 后重试），会瞬间打满服务端连接队列，形成“重连风暴”。这不是容错，是制造雪崩。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 基础策略用指数退避：
delay = Math.min(1000 * Math.pow(2, retryCount), 30000) - 必须叠加随机抖动：
delay += Math.random() * delay * 0.3（±30%浮动） - 总重试次数建议 ≤ 10 次；超过后应暂停自动重连，改由用户手动触发或提示“网络异常，请检查后刷新”
- 注意：
retryCount必须在onopen中清零，否则一次成功后下次断连会沿用旧计数
重连前必须清理旧连接和状态竞争
页面未刷新但网络反复抖动时，容易出现多个 WebSocket 实例并发存在，导致消息重复、token 冲突、内存泄漏。
- 用一个全局引用（如
wsRef）保存当前实例，每次新建前先执行wsRef?.close()并置空 - 加
isReconnecting标志位，防止onclose因多次触发而启动多条重连链 - 重连 URL 若含 token，务必在每次重连前重新获取——旧 token 可能已在上次断连期间过期，直接重用会导致循环失败
- 不要在
onmessage里调用重连函数；它可能在连接已关闭但事件队列未清空时被执行
真正难的不是写对这几行重连代码，而是让心跳、重连、状态清理、凭证更新四者节奏一致——任何一环脱节，都会让“稳定连接”变成间歇性失联。生产环境里，80% 的闪断问题其实出在心跳超时值和服务端保活配置不匹配，而不是前端重连逻辑本身。
