websocket断连检测不能依赖onclose，需主动ping探测；重连须防竞争、指数退避、区分code=1000/1006、动态刷新token。
onclose没触发？别等它，主动探测才是真断连信号
WebSocket连接“假在线”很常见：手机切后台、WiFi切4G、NAT超时，TCP连接还卡在ESTABLISHED，但服务端早把 socket 关了。这时候onclose永远不会来，光靠监听它等于守株待兔。
真正可靠的断连信号来自底层：比如socket.timeout、OSError、ConnectionRefusedError。尤其在 Python 的 websocket-client 中，必须配合ping_interval和ping_timeout主动发帧探测，而不是等系统 TCP keepalive（默认 2 小时，完全无效）。
-
ping_interval=20：每 20 秒发一次Ping帧（单位是秒，不是毫秒） -
ping_timeout=3：发完 3 秒内没收到Pong，就抛WebSocketConnectionClosedException - 中间设备（Nginx、云 LB、运营商 NAT）空闲超时常见为 45–90 秒，所以心跳间隔必须比最短的那个更激进
重连不能只写 setTimeout，得防状态竞争和雪崩
直接递归调用connectWebSocket()或在onclose里无条件setTimeout，很容易导致多个 WebSocket 实例并发存在，最终报错WebSocket is already in CLOSING or CLOSED state。
关键要加两层防护：
- 用一个全局引用
wsRef存当前实例，每次新建前先wsRef?.close()并置null - 用布尔标志
isReconnecting防止onclose被多次触发后重复启动重连逻辑 - 重连延迟必须指数退避：
1s → 2s → 4s → …，上限建议30s，总次数不超过10次；超限后暂停，提示用户手动刷新
code=1000 和 code=1006 必须区分对待
不是所有断开都该重连。onclose事件的event.code是决策依据：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
code === 1000：正常关闭，比如用户退出、服务端优雅下线——不重连 -
code === 1006：异常关闭，无 close 帧，大概率网络中断或服务端崩溃——立即走重连流程 -
code >= 4000：自定义业务码，如"token_expired"，需先刷新凭证再重连，否则会陷入死循环
漏判code=1000会导致用户点退出后还在后台疯狂重连；忽略code>=4000则 token 过期反复失败，前端日志刷屏。
重连时 token 没更新？连接永远建不起来
很多重连逻辑只管重建 WebSocket 实例，却忘了 URL 里的认证参数（比如?token=xxx）可能已过期。服务端一验就拒，前端又触发onclose，形成闭环失败。
正确做法是：
- 把 token 获取逻辑抽成异步函数，比如
async fetchToken() - 每次重连前先 await 它，拿到新 token 再拼 URL：
new WebSocket(`wss://api.com/ws?token=${await fetchToken()}`) - 如果 token 刷新也失败（如登录态丢失），应终止重连，跳转登录页
这个点不难，但上线后最容易被忽略——因为本地开发时 token 有效期长，问题压根不暴露。
