移动端h5 websocket频繁掉线需分层应对：监听visibilitychange事件精准感知切后台，用settimeout链式心跳替代setinterval，重连采用指数退避（1s→2s→4s→8s，上限30s），并协同服务端对齐超时配置与状态补偿。
移动端H5 WebSocket掉线频繁，不是前端代码写得不够“稳”，而是iOS/Android系统对后台页面的资源管控 + 中间件（Nginx、CDN、防火墙）静默断连 + 前端心跳机制缺失三者叠加的结果。单纯加大重连频率只会加重雪崩，必须分层应对。
监听 visibilitychange 而不是只靠 onclose
页面切后台时，iOS WKWebView 和 Android WebView 会冻结 JS 定时器、暂停网络任务，但 ws.readyState 可能仍为 WebSocket.OPEN —— 这是假活。此时发心跳失败、收不到 pong，但 onclose 往往延迟数秒甚至不触发。
- 必须监听
document.addEventListener('visibilitychange', () => { ... })，document.visibilityState === 'hidden'时立即停止心跳定时器、清空待发送队列，但不调用ws.close() -
visibilityState === 'visible'时，先检查ws.readyState !== WebSocket.OPEN，再触发重连，而不是直接复用旧实例 - 不要在
onclose里无条件重连：它可能在切后台后才触发，此时重连请求会被系统丢弃或超时
用 setTimeout 链式心跳，别用 setInterval
setInterval 在页面失焦、JS 主线程阻塞或系统节流下会严重漂移，导致心跳堆积（同一秒发多次）或漏发（休眠后长时间不触发），服务端判定超时就踢连接。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 心跳必须用
setTimeout实现链式调用：send() → 成功 → setTimeout(下一次)，每次发送前校验ws.readyState === WebSocket.OPEN - 心跳间隔建议设为服务端超时阈值的
2/3（例如服务端 idle timeout = 45s，则前端心跳间隔 = 30s） - 心跳消息格式必须和服务端约定一致：
{"type":"ping"}、"heartbeat"或二进制帧，不能只依赖浏览器底层 ping/pong（JS 层不可见）
重连必须带指数退避和状态标识
移动端网络切换（Wi-Fi→4G）、锁屏唤醒、App 切前后台等场景下，onclose 和 onerror 可能密集触发。无退避的立即重连会导致 QPS 暴涨、服务端拒绝或 NAT 表溢出。
- 重连延迟按指数增长：
1000ms → 2000ms → 4000ms → 8000ms，上限建议30000ms，连续失败 5 次后暂停自动重连 - 每次重连成功后，必须发送带唯一标识的重连消息，如
{"type":"reconnect","sid":"abc123"}，让服务端恢复上下文（未读消息、房间状态） - 重连前务必清除旧连接的
onmessage/onerror监听器、取消所有setTimeout，否则多个连接并存会互相干扰
服务端协同才是关键，前端单边优化无效
前端再精细的心跳和重连，也绕不开 Nginx proxy_read_timeout、阿里云 SLB 空闲超时、CDN 断连等基础设施限制。不和服务端对齐，所有努力都是临时补丁。
- 确认服务端是否开启标准 WebSocket 协议透传：Nginx 必须有
proxy_set_header upgrade $http_upgrade和proxy_set_header connection "upgrade" - 要求服务端将
proxy_read_timeout设为 ≥ 300s，并同步调整心跳间隔与之匹配（比如服务端 expect 每 90s 收到一次心跳） - 服务端需维护客户端最后活跃时间戳，切后台期间不清理会话；前台恢复时，先拉取离线摘要，再建立新连接，避免消息空窗
最容易被忽略的一点：PWA 场景下，Service Worker 可缓存鉴权响应和离线消息，但它本身也会被系统终止——不能指望它长期驻留，只适合做轻量级兜底。真正的稳定性来自“感知快、重建准、补偿全”，而不是试图让连接永不中断。
