浏览器自动处理WebSocket底层ping/pong帧，无需JS干预；但需在onmessage中响应业务层ping消息，并配合定时发送、超时检测与重连机制保障连接活性。
WebSocket 连接中，服务器主动发送心跳（如 ping 消息）时，客户端必须及时响应（通常发回 pong），否则服务器可能因超时断开连接。关键不是“自己发心跳”，而是**正确监听并应答服务器发来的 ping 帧**。
识别并响应服务器的 ping 帧
浏览器原生 WebSocket 对象不会把 ping/pong 帧暴露给 JS 层——它们由底层自动处理。也就是说：✅ 你无需手动监听 ping，也无需发 pong；浏览器已内置支持，只要连接正常，就会自动应答。
但注意：这个自动响应只在连接活跃、事件循环未被长时间阻塞的前提下生效。如果 JS 主线程卡死（比如执行超长同步计算），可能导致 pong 延迟发出，触发服务器断连。
用 message 类型消息模拟应用层心跳（更常见且可控）
多数实际项目中，“服务器心跳”其实是业务层约定的消息，例如：
立即学习“Java免费学习笔记（深入）”；
- 服务器定时发
{"type":"ping", "ts":171xxxx} - 客户端收到后立即回复
{"type":"pong", "ts":171xxxx}
这时需在 ws.onmessage 中判断并响应：
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
if (data.type === 'ping') {
ws.send(JSON.stringify({ type: 'pong', ts: data.ts }));
}
// ...处理其他业务消息
};
配合心跳维持连接活跃性
仅响应还不够，客户端也应主动探测连接状态。建议组合使用：
- 设置定时器，每 20–30 秒发一次
ping（业务消息） - 记录上次收到服务器消息的时间，超时（如 45 秒）未收则视为断连，尝试重连
- 监听
ws.onclose和ws.onerror，失败后指数退避重连
避免常见误区
❌ 不要试图用 ws.binaryType = 'arraybuffer' 拦截原始 ping 帧——浏览器不提供该能力。
❌ 不要依赖 setInterval 单纯发 ping 而不检查响应——可能掩盖真实断连。
✅ 推荐用 setTimeout + 时间戳标记做单次心跳超时控制，更精准可靠。
