WebSocket需客户端主动实现心跳机制：定时发送ping（20–30秒间隔）、监听服务端pong响应、超时重连、状态校验与清理。服务端须及时回应pong，配合调试与生产优化。
WebSocket 连接默认没有内置心跳机制，长时间空闲容易被中间代理（如 Nginx、负载均衡器）或防火墙主动断开。客户端需主动发送心跳消息（ping），服务端响应（pong）来维持连接活跃。关键在于：定时发 ping、监听 pong 响应、超时重连、避免重复发送。
设置定时 ping 发送
使用 setInterval 定期向服务端发送心跳消息（通常为字符串 "ping" 或自定义类型）。建议间隔 20–30 秒，略短于服务端配置的超时时间（如 Nginx 的 proxy_read_timeout 默认 60 秒）。
- 在 WebSocket 连接打开后（
onopen）启动定时器 - 使用
clearInterval在关闭或异常时清理，防止内存泄漏 - 避免在未连接（
readyState !== 1）时发送，可加状态判断
监听 pong 响应并管理超时
服务端收到 ping 后应回复 pong（如 "pong"），客户端需监听该响应并重置超时计时器。若未在预期时间内收到 pong，则判定连接异常。
- 用
setTimeout设置单次响应等待（如 5 秒），超时触发重连逻辑 - 每次收到合法 pong 后清除旧定时器、重设新定时器
- 推荐将 ping/pong 封装为带唯一 ID 的 JSON 消息（如
{"type":"ping","id":123}），便于匹配和防误判
处理连接异常与自动重连
心跳失败不等于连接已断，但属于高危信号。此时应主动关闭旧连接、延迟重试，并限制重连次数防止雪崩。
立即学习“Java免费学习笔记（深入）”；
- 在
onclose和onerror中停止心跳定时器 - 心跳超时后调用
ws.close()，再延时（如 1–3 秒）尝试重建连接 - 记录连续失败次数，超过阈值（如 5 次）暂停重连或提示用户
- 重连时更新 URL 参数（如加时间戳）避免缓存旧连接
补充建议：服务端配合与调试技巧
客户端心跳需服务端明确支持——仅发 ping 不响应 pong，客户端无法确认链路是否通畅。开发阶段可通过浏览器开发者工具的 Network → WS → Frames 查看收发帧，验证 ping/pong 是否正常流转。
- 服务端收到 ping 应立即返回对应 pong，不要排队或延迟
- 避免将心跳消息写入业务日志，减少干扰
- 生产环境开启 WebSocket 的
binaryType为"arraybuffer"可提升小消息效率（非必需）
