websocket客户端心跳检测需主动定时发送"ping"并验证"pong"响应，结合超时机制判断连接状态；须手动管理定时器、严格校验消息内容、清理残留任务，并与服务端协同设计。
WebSocket 客户端心跳检测的核心是：主动定时发送 ping 消息（如字符串 "ping"），并监听服务端返回的 pong 响应，结合超时机制判断连接是否存活。
手动实现心跳发送与响应验证
浏览器原生 WebSocket 不提供内置心跳，需自行管理定时器和消息收发逻辑。关键点在于区分“发送心跳”和“确认心跳有效”——不能只发不等回，也不能把收到任意消息当作 pong。
- 使用
setInterval定期调用ws.send("ping")，建议间隔 20–30 秒（避开服务端超时阈值） - 在
ws.onmessage中判断数据内容：if (event.data === "pong") { resetHeartbeatTimeout(); } - 单独维护一个心跳超时定时器（
setTimeout），每次发 ping 时清除旧定时器、新建一个（例如 10 秒后触发断连逻辑） - 超时触发时，调用
ws.close()并可尝试重连，避免残留假连接
避免常见陷阱
心跳不是越频繁越好，也不是所有返回都算有效响应。实际开发中容易踩坑：
-
别依赖
onclose自动感知断连：网络中断时，客户端可能长时间收不到任何事件，必须靠心跳超时主动发现 -
不要把业务消息当 pong：服务端应明确区分心跳响应（如固定返回
"pong"），客户端需严格校验内容，而非仅看是否收到消息 -
重连前先清理定时器：断开或重连时，务必
clearInterval和clearTimeout，否则多个心跳任务会叠加执行 - 考虑服务端兼容性：部分服务端用 WebSocket 协议原生 ping/pong 帧（浏览器自动处理），但多数 Web 应用层心跳走文本消息，需前后端约定一致
封装成可复用的心跳管理模块
把心跳逻辑抽离为独立类，提升可维护性。例如：
- 构造时传入
WebSocket实例、ping 内容、超时毫秒数 - 提供
start()/stop()方法控制心跳开关 - 内部自动绑定
onmessage，匹配 pong 后重置超时；超时回调暴露为onHeartbeatFail - 支持自定义心跳失败后的动作（如日志、通知、重连）
配合服务端协同设计
客户端心跳必须和服务端策略对齐才真正可靠：
- 服务端收到
"ping"后必须及时回复"pong"，延迟不应超过客户端超时时间 - 服务端也应实现自己的心跳检测（如记录最后消息时间），主动踢掉无响应客户端
- 建议双方都启用 TCP keepalive（底层），作为心跳机制的补充，但不可替代应用层心跳
- 首次连接建立后，客户端可立即发一次 ping，快速确认链路可用性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
