WebSocket长连接不超时技巧

WebSocket 长连接极易因代理、防火墙或负载均衡器的空闲超时而被静默断开，但浏览器原生 API 并不支持直接发送或监听协议级的 Ping/Pong 帧——所谓 `ws.ping()` 或 `onpong` 事件纯属误解且在标准环境中会报错或失效；真正可靠的做法是**用应用层 JSON 消息（如 `{"type":"ping"}`）模拟双向心跳**：客户端定时发送、服务端立即响应、双方协同维护活跃状态并精准检测超时；同时必须兼顾移动端后台冻结、服务端僵尸连接清理、消息全路径活性判定等关键细节，否则连接将在无声无息中“假在线、真断连”。

浏览器原生 WebSocket API **根本不支持调用底层 Ping/Pong 控制帧**，所谓“HTML 的 WebSocket ping pong 机制”是常见误解——你无法在前端 JavaScript 中主动发送或监听标准 WebSocket 协议级的 Ping 帧，onping、onpong 事件也不存在。

为什么不能直接用浏览器的 ping/pong 帧

WebSocket 协议确实定义了 Ping 和 Pong 控制帧，但 W3C 规范明确禁止 JavaScript 暴露这些帧的控制权。浏览器会自动响应服务端发来的 Ping（回 Pong），但你既不能触发它，也无法捕获这个过程。这意味着：

• 仅靠服务端启用 pingTimeout（如 Node.js ws 库）只能检测客户端是否“断线”，但客户端完全感知不到 —— readyState 可能还显示 OPEN，后续 send() 却静默失败
• 若依赖“浏览器自动回 pong”，你就失去了超时判定能力，无法主动关闭或重连
• 所有声称 ws.ping() 或 ws.onpong = ... 的代码，在标准浏览器中都会报错或静默忽略

必须用应用层消息模拟心跳（ping/pong）

真实可行的做法是：用普通文本或 JSON 消息模拟心跳协议，由双方约定字段和行为。关键不是“像不像协议帧”，而是“能否可靠探测双向活性”：

• 客户端定时发送 {"type":"ping","ts":Date.now()}，间隔建议设为中间设备超时阈值的 2/3（例如 Nginx 默认 proxy_read_timeout 60s，则设 40s）
• 服务端收到后，**立即**返回 {"type":"pong","ts":Date.now(),"from":"server"}，不走业务逻辑链路（跳过鉴权、日志、数据库）
• 客户端收到 type === "pong" 时，清除上次启动的超时定时器，并记录 RTT；若 setTimeout 超时未收到，则 ws.close(4001, "heartbeat timeout")
• 同时监听 onmessage 中任意业务数据，也视为活跃信号 —— 避免“只靠 ping 不收业务包”的误判

服务端必须配合记录 lastActive 并清理死连接

光客户端发没用。服务端得把每个 socket 的最后活跃时间记下来，并主动踢掉僵尸连接：

• 连接建立时，绑定 socket.lastActive = Date.now()（推荐用 Map 存，别挂实例上防内存泄漏）
• 每次收到 ping 或任意业务消息，都更新该时间戳
• 启动独立定时任务（如每 25s 扫描一次），对 Date.now() - socket.lastActive > 90000 的连接调用 socket.terminate()（比 close() 更彻底）
• 务必监听 socket.on("close") 和 socket.on("error")，及时从活跃 Map 中删除对应项

移动端和小程序要额外处理 visibilitychange 和 background

用户切到后台或锁屏后，浏览器可能冻结 setInterval，导致心跳停发，但服务端还在等 —— 结果就是 60 秒后被强关。必须做适配：

• 监听 document.addEventListener("visibilitychange", () => { if (document.hidden) stopHeartbeat(); else startHeartbeat(); })
• 微信小程序用 wx.onAppHide/wx.onAppShow；React Native 用 AppState 监听
• 若页面不可见超过 30s，暂停发 ping，但不要清空 lastActive —— 否则一回来就立刻被服务端踢
• 恢复可见时，先发一次 ping，收到 pong 再恢复常规心跳节奏

真正容易被忽略的点是：心跳不是单向计时器，而是一套闭环状态机。客户端发 ping → 启动等待定时器 → 收到 pong 或业务消息 → 清除定时器 → 更新本地活跃标记；服务端收消息 → 更新 lastActive → 定期扫描 → 发现超时 → 强制终止。少一环，连接就在你看不见的地方悄悄死亡。

到这里，我们也就讲完了《WebSocket长连接不超时技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！