前端websocket断网提示不能仅依赖navigator.online，因其仅反映浏览器自认为的联网状态，存在假阳性；必须结合onclose、onerror事件与心跳超时三者交叉判断，才能准确定位真实断网并触发提示。
前端 WebSocket 断网自动提示不能只靠 navigator.onLine，它常返回假阳性（比如锁屏后仍为 true），必须结合 onclose、onerror 和心跳超时三者交叉判断才能准确定位断网并触发提示。
为什么 navigator.onLine 不可靠
它只反映浏览器“自认为”是否联网，不检测 WebSocket 实际连通性。例如：
- 手机锁屏后 Wi-Fi 未断，但后台心跳已失效，
navigator.onLine仍为true - Chrome 在断电或代理异常时可能缓存旧状态，长时间不更新
- CDN 或 LB 中间层静默断连，客户端连接状态仍是
OPEN，但onLine也无变化
所以它只能作为辅助信号——网络恢复时可触发重连检查，但绝不能用于“判断是否已断网”。
onclose 和 onerror 是真实断连的主判据
移动端断连最常见表现是 onclose 触发且 event.code === 1006（异常关闭），或 onerror 被静默调用（无具体错误信息）。关键处理逻辑：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
-
onclose中检查event.wasClean === false或event.code === 1006，满足任一即标记为“非预期断开” -
onerror不要立刻重连，应设防抖（如 500ms 内只触发一次）并交由统一重连控制器调度 - 断开后立即清空旧定时器（如心跳、重连计时器），避免资源泄漏和重复触发
- 调用
ws.close()显式关闭实例，再新建连接，防止残留连接干扰
心跳超时才是最灵敏的“断网感知器”
服务端未配置心跳保活时，客户端可能数分钟都收不到任何消息，但连接状态仍是 OPEN。此时需自己实现双向心跳检测：
- 客户端每 30s 发送
{type: "ping"}，同时启动一个 15s 的serverTimeoutTimer - 只要收到任意服务端消息（
pong或业务数据），就clearTimeout(serverTimeoutTimer) - 若超时未响应，直接触发断网提示 + 重连流程，不等
onclose回调 - 心跳包内容建议带时间戳，便于服务端校验延迟，避免被中间设备丢弃
自动提示文案与用户感知设计
提示不是越频繁越好，重点在“可操作性”和“状态透明”：
- 首次断开：显示“网络不稳定，正在尝试恢复…”（不暴露技术细节）
- 重连失败 3 次后：改为“连接中断，请检查网络后点击重试”，并提供手动重连按钮
- 重连成功后，补发未送达消息前，禁用发送框并显示“同步中…”
- 避免弹窗打断操作，优先使用顶部 banner 或右下角 toast，2 秒后自动消失（除非用户交互）
真正难的是心跳与重连的节奏配合：心跳太密增加弱网负担，太疏又无法及时感知；重连间隔不按指数退避（1s→2s→4s…上限 60s），容易引发雪崩。这些细节一旦漏掉，用户看到的就不是“自动恢复”，而是反复闪退的提示框。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
