WebSocket断开后自动重连需监听onclose和onerror事件，通过标志位防重复、指数退避（1s起，上限30s，限10次）控频率，重建前清理旧连接并校验currentWs状态，配合心跳机制（ping/pong）探测假在线。
WebSocket 连接断开后自动重连，核心是监听 onclose 和 onerror 事件，在回调中延时重新调用 new WebSocket()，同时需避免无限重连、重复连接、状态混乱等问题。
监听关闭与错误，触发重连逻辑
WebSocket 实例的 onclose（服务端主动断开或网络中断）和 onerror（连接失败、协议错误等）是重连的主要入口。注意：onerror 触发时连接对象通常已不可用，不能调用 close()；onclose 中也不应再调用 close()。
- 在
onclose中检查event.code和event.reason，跳过预期关闭（如 code === 1000） -
onerror不代表连接一定未建立，但多数情况下应视为连接失败，可统一走重连流程 - 为防止多次触发，建议设置一个标志位（如
isReconnecting），重连开始前置为true，成功连接后重置
实现指数退避 + 最大重试次数
连续快速重连会加重服务端压力，也易被防火墙拦截。推荐使用指数退避策略：首次延迟 1s，第二次 2s，第三次 4s……上限设为 30s，并限制总重试次数（如 10 次）。
- 用闭包或实例属性记录当前重试次数和基础延迟（如
retryCount = 0，baseDelay = 1000） - 每次重连前计算延迟：
delay = Math.min(baseDelay * Math.pow(2, retryCount), 30000) - 重试次数达到上限后停止自动重连，可触发全局提示或交由用户手动恢复
确保连接唯一性与状态同步
重连过程中，旧连接可能仍在执行 onmessage 或尚未完全销毁，新连接又已建立，导致消息乱序或重复处理。
立即学习“Java免费学习笔记（深入）”；
- 每次新建 WebSocket 前，先清除上一个实例的事件监听器（
ws.onmessage = null等），并显式调用ws.close()（如果仍处于OPEN或CONNECTING状态） - 维护一个
currentWs引用，所有发送操作（send()）前判断currentWs?.readyState === WebSocket.OPEN - 重连成功后，重新发送未确认的关键消息（如登录态、订阅指令），可通过本地队列 + 序号/时间戳去重
补充：心跳保活与连接有效性检测
仅靠自动重连不够——长连接可能“假在线”（TCP 连接未断，但应用层已失效）。需配合心跳机制主动探测。
- 客户端定时（如每 30s）发送
ping消息（自定义类型，如{"type":"ping"}），服务端必须响应pong - 若连续 2–3 次未收到
pong，主动close()并触发重连流程 - 心跳超时判定需独立于 WebSocket 原生
onclose，避免因网络抖动误判
