WebSocket断连后需按原因区分重连策略：code=1000不重连，1006或≥4000需重连；采用指数退避（1s起、上限30s、最多10次）；通过wsRef和isReconnecting防重复连接；加心跳机制（30s ping/5s未pong则主动断连）并同步更新token。
WebSocket连接自动断开后，靠前端主动重连是必要手段。关键不是“立刻重试”，而是控制重连节奏、避免雪崩、识别真实断连，并在合适时机恢复通信。
判断断连原因并区分重连策略
不是所有 close 都该立即重连。需监听 onclose 事件的 event.code 和 event.reason：
- code = 1000（正常关闭）：无需重连，可能是用户主动退出或服务端优雅下线
- code = 1006（异常关闭，无 close 帧）：大概率网络中断或服务端崩溃，应启动重连
- code ≥ 4000：自定义业务错误码，可结合 reason 判断是否允许重连（如 “token_expired” 需先刷新凭证）
实现指数退避 + 最大重试限制
连续快速重连会加重服务端压力，也易被防火墙限流。推荐从 1s 开始，每次翻倍，上限设为 30s，总尝试次数不超过 10 次：
- 第 1 次：延迟 1s 后重连
- 第 2 次：延迟 2s
- 第 3 次：延迟 4s
- ……直到达到 30s 或重试达上限
- 超限后暂停重连，可提示用户“连接不稳定，请稍后手动刷新”
避免重复连接与状态竞争
多个重连定时器或用户快速刷新页面，容易导致多个 WebSocket 实例并发连接。应在重连前检查当前连接状态：
立即学习“前端免费学习笔记（深入）”；
- 用一个变量（如
wsRef）保存当前 WebSocket 实例 - 每次新建连接前，先调用
wsRef?.close()（若存在且未关闭） - 设置
wsRef = null，并在onopen中重新赋值，确保唯一性 - 用布尔标志（如
isReconnecting）防止 onclose 触发多次重连逻辑
心跳保活 + 断线感知增强
仅依赖 onclose 不够及时（TCP 层可能长时间不触发）。建议增加应用层心跳：
- 连接建立后，每 30s 发送一次
{"type":"ping"} - 服务端必须响应
{"type":"pong"} - 前端维护一个定时器，若 5s 内未收到 pong，则主动
ws.close(4999, "no_pong")，触发重连流程 - 此机制能更快发现“假连接”（如 NAT 超时、中间代理静默丢包）
不复杂但容易忽略：重连时记得同步更新认证凭证（如 token），避免因过期反复失败；服务端也应支持连接 ID 复用或消息补推，提升用户体验。
