websocket需应用层实现双向心跳保活：客户端每20–30秒发"ping"并设5–10秒超时，服务端及时回"pong"；双方配合自动重连与状态同步，避免代理断连。

WebSocket 连接默认没有内置心跳机制，长时间无数据交互时，中间代理（如 Nginx、负载均衡器）或防火墙可能主动断开空闲连接。要维持连接活跃，需在应用层实现心跳检测：客户端定时发 ping 消息，服务端响应 pong，双方共同监控超时状态。

客户端心跳发送与超时判断

使用 setInterval 定期调用 ws.send() 发送自定义心跳消息（如 "ping"），同时设置定时器等待服务端响应。若在约定时间内未收到 "pong"，视为连接异常，可触发重连。

• 建议间隔 20–30 秒发送一次 ping，超时阈值设为 5–10 秒，避开常见代理的 60 秒空闲断连限制
• 发送前检查 ws.readyState === WebSocket.OPEN，避免向关闭或未建立连接发送消息
• 每次发送 ping 前清除旧定时器，收到 pong 后重置超时计时器，防止误判

服务端响应与连接保活

服务端监听客户端发来的 "ping" 消息，立即返回 "pong"（或直接调用 ws.ping()，取决于框架是否支持自动处理）。关键是要确保响应及时且不被业务逻辑阻塞。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• Node.js + ws 库中，可监听 message 事件识别 ping，并用 ws.send("pong") 回复；也可启用 websocket.ping() 触发底层 ping/pong 帧（更轻量）
• 避免在处理 ping 时执行耗时操作；心跳响应应独立于业务逻辑，保证低延迟
• 服务端也建议维护连接活跃度，例如记录最后通信时间，定期清理长时间无响应的客户端

双向心跳 + 自动重连策略

仅客户端发 ping 不足以覆盖所有断连场景（如网络闪断、服务端崩溃）。推荐客户端和服务端都启动心跳，并配合连接状态管理与智能重连。

• 客户端在 onclose 或心跳超时时启动重连，采用指数退避（如 1s → 2s → 4s → 最大 30s）避免雪崩请求
• 连接恢复后重新初始化心跳定时器，并同步必要状态（如订阅主题、会话 ID）
• 可结合 onerror 和 onmessage 中的时间戳，辅助判断是网络问题还是服务端异常

注意兼容性与调试细节

原生 WebSocket 的 ping/pong 帧不可见（浏览器 API 不暴露），所以必须用应用层消息模拟。调试时可通过服务端日志、onmessage 监听、浏览器开发者工具的 Network → WS → Frames 查看实际收发内容。

• 不要依赖 ws.ping() 在浏览器端调用——它只在 Node.js ws 库中有效，浏览器不支持该方法
• 心跳消息尽量简洁（如纯字符串 "ping"），避免序列化开销和解析错误
• 服务端若使用 Socket.IO 等封装库，其自带心跳机制（pingInterval/pingTimeout），无需手动实现，但需确认配置生效

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南