移动端WebSocket频繁断线主因是系统冻结JS和关闭空闲连接，需手动实现visibilitychange监听、主动清理旧连接、onclose/onerror精准判据、指数退避重连、心跳保活及后台降级策略。
移动端 WebSocket 频繁断线不是“网络不好”就能糊弄过去的，核心问题是：浏览器或系统在锁屏、切后台、切换网络时会主动冻结 JS 执行、关闭空闲连接，而 WebSocket 实例本身对此毫无感知——必须靠你手动补全状态判断和重连逻辑。
监听 visibilitychange 处理锁屏与切后台
手机锁屏后，Chrome/Safari 会暂停定时器、中断心跳发送，十几秒后服务端就因收不到 ping 主动断连。不能等 onclose 触发才反应，得提前干预：
- 用
document.addEventListener('visibilitychange', ...)捕获页面隐藏/显示时机 - 页面隐藏时（
document.visibilityState === 'hidden'），立即清除当前心跳定时器（如clearInterval(pingTimer)） - 页面重新可见时，若距隐藏已超 10 秒（
(visibleTime - hiddenTime) / 1000 > 10），不直接重连，而是先调用websocket.close()主动清理旧连接，再延时 1.5s 启动新连接（避免 close 尚未完成就 new WebSocket） - 注意：iOS Safari 在锁屏后可能直接销毁
WebSocket实例，此时websocket.readyState可能已是CLOSED或0，需判空再操作
用 onclose 和 onerror 做主断连判据，别信 navigator.onLine
navigator.onLine 在移动端基本不可靠——Wi-Fi 信号弱但返回 true、锁屏后仍为 true 却早已断连。真实断连信号只能来自连接自身：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
onclose中检查event.wasClean === false或event.code === 1006（异常关闭），这类是明确需要重连的 -
onerror通常不带具体错误码，但只要触发，就标记连接失效，交由统一重连控制器处理，不要在onerror里直接new WebSocket()（易造成重连风暴） - 每次触发重连前，务必检查
document.hidden：若仍为true，暂缓重连；否则立即走指数退避流程
实现带退避的重连 + 心跳保活
重连不是“断了就试”，而是要控频、控态、控资源：
- 初始延迟 1000ms，失败后翻倍（2000 → 4000 → 8000…），上限设为 60000ms（1分钟），避免雪崩
- 客户端每 25 秒发一次
{type: 'ping'}，服务端必须回{type: 'pong'}；连续 2 次未收到 pong，主动websocket.close()并触发重连 - 每次重连前，确保清除上一轮的
pingTimer、reconnectTimer和所有事件监听器（websocket.removeEventListener('message', handler)），否则旧监听器残留会导致消息重复处理 - 重连成功后，立刻发一条
{type: 'reconnect', sessionId: 'xxx'}，让服务端恢复上下文（如未读消息队列、房间成员状态）
Android/iOS 后台保活的现实约束
想让 App 在后台持续维持 WebSocket 连接？现实是：iOS 不允许，Android Doze 模式下也极难保证。别把精力花在“后台保活”上，转而优化前台恢复体验：
- iOS：BGTaskScheduler 最多给你 30 秒后台执行时间，且必须用户近期使用过 App，无法用于长期心跳
- Android：Doze 模式下网络请求被延迟合并，
WebSocket必然断开，强行保活会触发系统杀进程 - 真正可行的方案是：锁屏/切后台时优雅降级（暂停心跳、释放资源），唤醒后快速重连+状态同步，而非硬扛不断连
最容易被忽略的一点：重连不是“新建一个 WebSocket 实例”就完事了——旧实例的事件监听器、定时器、引用如果没清干净，轻则内存泄漏，重则多个连接并发发送重复消息，服务端状态直接错乱。
