移动端websocket断连高发于网络切换场景，需通过监听网络事件、延迟重连、主动关闭旧连接、动态调整心跳参数及引入状态机等策略实现可靠通信。

频繁切换网络（比如从 Wi-Fi 切到 4G/5G，或地铁进出隧道）是移动端 WebSocket 断连的高发场景。这不是“信号差”就能解释的问题，而是系统和中间设备在连接状态突变时缺乏协同感知——必须靠客户端主动适配，而非等待重连。

监听网络变化 + 延迟重连

不能一检测到 navigator.onLine 变为 true 就立刻 new WebSocket。很多情况下，网络刚恢复但 IP 未分配完、DNS 未就绪、NAT 表未重建，此时强行建连大概率失败。

• 用 window.addEventListener('online', ...) 捕获上线事件，但触发后先延时 1.2–2 秒再启动重连流程
• 结合 fetch('/health') 或轻量 HTTP 探针（如 GET /ping），确认网络栈真正可用后再建 WS
• 若连续两次探针失败，跳过本次重连，等待下一次 online 事件

切网瞬间主动关闭旧连接

网络切换时，旧 socket 往往卡在 CONNECTING 或 OPEN 状态，但底层 TCP 已失效。继续保留它会干扰新连接建立，还可能残留监听器导致消息错乱。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 监听 window.addEventListener('offline', () => { if (ws && ws.readyState > 0) ws.close(4999, 'network switch'); })
• close 后立即清理 ping 定时器、reconnectTimer 和所有 message/error/close 监听器
• 避免在 offline 时尝试 send()，防止触发 unhandled rejection

心跳与超时参数动态调整

固定 30 秒心跳在弱网切换中容易被误判为断连。应根据当前网络类型缩放心跳周期和响应窗口：

• 通过 navigator.connection.effectiveType（如 '4g'、'slow-2g'）获取粗略网络质量
• effectiveType 为 'slow-2g' 或 '2g' 时：心跳间隔设为 45 秒，pong 超时设为 12 秒
• effectiveType 为 '4g' 或 '5g' 时：心跳间隔 25 秒，pong 超时 6 秒
• 无 navigator.connection 支持时，默认按中等网络处理（30 秒 / 8 秒）

连接状态机 + 后台降级策略

单纯靠 readyState 判断连接是否有效，在切网场景下极易误判。需引入显式状态机，并对后台场景做区分处理：

• 定义状态：IDLE → CONNECTING → OPEN → CLOSING → CLOSED，每次状态变更记录 timestamp
• 页面 visibilityState === 'hidden' 且距上次心跳响应 > 40 秒时，不触发重连，只标记为 SUSPENDED
• 重新 visible 且状态为 SUSPENDED 时，先 close() 再 wait 1.5s 后新建连接（避免 close 未完成就复用）
• iOS Safari 锁屏后可能直接销毁实例，每次操作前需检查 ws && ws.readyState !== undefined