websocket移动端断连需手动实现健壮重连：以onclose/onerror为主判据，结合navigator.online辅助；采用指数退避（1s→2s→4s…，上限60s）；加入心跳保活与重连标识；清除旧连接资源，确保单实例。

WebSocket在移动端遇到网络切换（比如从Wi-Fi切到4G/5G，或进入弱网、离线状态）时极易断开，而HTML5本身不提供自动重连机制，必须手动实现健壮的重连逻辑。关键不是“立刻重连”，而是要结合网络状态、连接状态、退避策略和用户感知来设计。

监听网络状态变化，但别全信navigator.onLine

navigator.onLine只是粗略指示浏览器是否认为联网（例如Chrome在断电后仍可能返回true），不能准确反映WebSocket是否可用。但它可作为辅助信号：

• 监听window.addEventListener('online', ...)和'offline'事件，在恢复网络时触发重连检查
• 但不要仅靠它决定是否重连——比如手机锁屏后Wi-Fi未断但WebSocket心跳已失效，onLine仍是true
• 建议配合WebSocket自身的onclose和onerror回调做主判断

用onclose和onerror捕获真实断连

移动端断连常表现为onclose（带code=1006表示异常关闭）或onerror（无具体错误码）。需统一处理：

• 在onclose中检查event.wasClean === false或event.code === 1006，视为非预期断开
• onerror通常不抛具体错误，但可标记“连接不可用”，触发重连流程
• 避免在onerror里直接重连（可能频繁触发），应设防抖或交由重连控制器统一调度

实现指数退避重连，防止雪崩

盲目轮询重连会浪费资源、加重服务器压力，尤其在弱网下更易失败。推荐使用指数退避（Exponential Backoff）：

• 初始延迟1秒，每次失败后翻倍（1s → 2s → 4s → 8s…），上限建议30–60秒
• 记录连续失败次数，达到阈值（如5次）后暂停重连，等待用户操作（如点击“重试”）或网络事件唤醒
• 每次重连前检查document.hidden：若页面在后台（如App切到后台、手机锁屏），可暂缓重连，避免无效尝试

加入心跳保活与服务端同步状态

单纯依赖TCP keep-alive不可靠，移动端NAT超时、代理中断等场景下连接可能“假活”。需应用层心跳：

• 客户端每15–30秒发ping消息（如{type:'ping'}），服务端立即回pong
• 若连续2–3次未收到pong，主动close()并触发重连，比等TCP超时更快感知异常
• 重连成功后，建议发送“重连标识”（如{type:'reconnect', sessionId: 'xxx'}），让服务端恢复上下文（如未读消息、房间状态）

不复杂但容易忽略：重连时要清除旧连接的定时器、事件监听器，并新建WebSocket实例；避免多个连接同时存在导致状态混乱。保持连接对象单一引用，用readyState严格校验状态再发消息。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！