websocket心跳需手动实现，核心是“发得准、收得回、断得清”：客户端主动ping或服务端ping+客户端自动pong，结合可见性节流与pong响应验证连接健康。

WebSocket 本身不自动发心跳包，必须手动实现。核心不是“发得多”，而是“发得准、收得回、断得清”——重点在控制节奏、验证响应、及时清理。

客户端主动发 ping（最常用）

服务端通常设空闲超时（如 60 秒），前端需在它之前发送心跳，留出网络余量：

• 连接建立后立即启动，用 setTimeout 链式调用，别用 setInterval（易堆积、后台失准）
• 推荐间隔 30–45 秒，比服务端超时短 10–15 秒
• 发前检查 ws.readyState === WebSocket.OPEN，或直接 try/catch send，失败就 close 触发重连
• 内容尽量轻：纯字符串 "ping" 比 JSON 快，避免序列化开销

服务端发 ping、客户端自动 pong（最省心）

浏览器对标准 Ping/Pong 帧有原生支持，客户端无需写响应逻辑：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 服务端（如 Node.js ws 库）调用 ws.ping() 发送 ping 帧
• 客户端收到后，浏览器自动回 pong 帧，不触发 onmessage
• 服务端监听 ws.on('pong', ...) 重置存活计时器，超时未收到则断连
• 这种方式客户端代码零负担，适合多数业务场景

结合页面可见性与连接状态动态节流

心跳不是越勤越好，后台/锁屏时继续发只会耗电、占流量：

• 监听 document.addEventListener('visibilitychange', ...)
• 页面隐藏时 clearTimeout 当前心跳定时器，暂停发送
• 重新可见时立即补发一次 ping，并重启检测逻辑
• 每次发 ping 后启动独立 timeout（如 10 秒），等 pong；收到 pong 就 clearTimeout 并设下一轮，避免多个 timer 并发

心跳响应要参与连接判断，不能只发不验

单向发 ping 不等于连接健康，必须靠 pong 确认双向通路：

• 仅靠 onclose/onerror 不够——断网瞬间这些事件不触发，send 才会暴露问题
• 把 pong 响应作为“连接存活”的唯一可信信号
• 连续几次没收到 pong，再触发重连，比单纯超时更可靠
• pong 消息只需校验 type 字段，跳过时间戳比对等可选逻辑，降低解析成本

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