WebSocket“假活”需客户端主动心跳检测：定时发ping、服务端必须响应pong、客户端超时未收pong即close，配合onclose/onerror健壮处理与重连机制。
WebSocket 连接看似建立成功，但网络中断、服务端异常下线、NAT 超时或防火墙静默丢包，都可能导致连接“假活”——客户端仍认为在线，实际已无法收发消息。此时仅靠 onclose 或 onerror 很难及时感知。解决的关键是：**客户端主动发心跳，服务端响应，客户端超时未收到响应即断开连接**。
1. 客户端定时发送心跳（ping）
使用 setInterval 每隔固定时间（如 30 秒）向服务端发送一个轻量消息（如字符串 "ping" 或自定义类型对象）。注意避开连接未就绪或已关闭状态：
- 只在
ws.readyState === WebSocket.OPEN时发送 - 避免在
onclose后继续发心跳（可配合clearInterval清理） - 推荐用二进制或短文本减少开销，例如：
ws.send(JSON.stringify({ type: "ping" }))
2. 服务端必须响应 pong（不能只忽略 ping）
仅发 ping 不够——如果服务端不回 ack，客户端无法判断是丢包还是服务端宕机。服务端收到 ping 后应立即返回明确的 pong 响应（如 {"type":"pong"}），且最好不排队、不延迟。常见错误：
- 服务端收到 ping 后无任何响应（心跳机制失效）
- 服务端把 pong 推入业务队列，延迟几秒才发出（导致客户端误判超时）
- 服务端用 WebSocket 原生
ping/pong帧但客户端未监听（浏览器中 JS 无法捕获原生 ping/pong 帧）
✅ 正确做法：统一走应用层协议，ping/pong 都用 send 和 onmessage 处理。
立即学习“Java免费学习笔记（深入）”；
3. 客户端设置超时检测与主动断连
每次发 ping 时启动一个定时器（如 5 秒），等待服务端 pong。若定时器触发前未收到 pong，则判定连接异常，调用 ws.close() 并可触发重连逻辑：
- 用
setTimeout+clearTimeout管理单次超时，每次 ping 前清除上一次定时器 - 收到 pong 后立即
clearTimeout，并可更新最后活跃时间 - 超时后执行
ws.close(4001, "heartbeat timeout")，便于服务端日志识别原因 - 断开后建议延迟重试（如指数退避），避免雪崩
4. 补充健壮性细节
真实场景还需考虑边界情况：
-
不要依赖
onerror：它不保证在断网时触发，尤其静默丢包场景基本不触发 - 监听
onclose时检查event.code和event.reason，区分是主动关闭还是心跳超时断开 - 连接恢复后重置心跳计时器，避免刚连上就因旧定时器超时误断
- 可加简单“存活标记”，如每次成功收/发消息都更新
lastActiveTime，辅助判断是否真死链
