心跳间隔设成15秒最稳妥，但必须同步调大Nginx的proxy_read_timeout、用JSON格式发包、客户端避开后台冻结、服务端加pong超时检测，四者缺一不可。
心跳间隔设成 15 秒最稳妥，但光设这个数没用——必须同步调大 nginx 的 proxy_read_timeout、用 json 格式发包、客户端避开后台冻结、服务端加 pong 超时检测，四者缺一不可。
为什么固定 30 秒心跳在生产环境大概率失效
很多教程直接写 setInterval(() => ws.send('ping'), 30000)，上线后却频繁断连。这不是代码错，而是中间设备根本“看不见”这个 ping：家用路由器 NAT 超时多在 60–120 秒，但移动 4G 网络有些运营商会激进地设成 30 秒；更关键的是，阿里云 SLB、腾讯云 CLB 这类负载均衡器只认 TCP 数据包，不解析 WebSocket 帧——如果你的心跳是纯字符串 "ping"，它可能被当成无效流量丢弃。
实测发现，同样设 30 秒，用 {"type":"ping"} 比用 "ping" 的断连率低 70% 以上，因为 JSON 格式更容易被网关识别为合法业务数据。
- 不要用
setInterval直接发心跳，移动端切后台后它会被系统暂停（iOS Safari 可能降频到 5 分钟一次） - 必须监听
visibilitychange事件，页面不可见时立刻发一次心跳并重置定时器 - 服务端收到
ping后不能只回pong就完事，要绑定超时检查：30 秒内没收到客户端pong，主动ws.close(4001, "pong timeout")
Nginx 和云厂商代理必须改的三个配置项
WebSocket 连接不是断在你代码里，是断在 Nginx 或 SLB 的默认超时上。阿里云 SLB 默认 proxy_read_timeout 是 60 秒，意味着只要后端 60 秒没往客户端发数据，连接就被静默 FIN 掉——哪怕你客户端每 15 秒都在发心跳。
这些配置必须同时生效：
-
proxy_read_timeout至少设为心跳间隔 × 3（例如心跳 15 秒，这里填45或300），留出网络抖动余量 -
proxy_send_timeout也要同步调大，否则服务端回pong稍慢一点也会被掐 - 确认你改的是哪一层的 Nginx：如果是走 SLB/CLB，得在云控制台调整其后端健康检查路径（如
/health）和空闲超时；如果是自己 ECS 上装的 Nginx，才改本地nginx.conf
客户端心跳要绕开浏览器后台冻结
iOS Safari 和 Android Chrome 在标签页切到后台时，会暂停 JavaScript 定时器。你看到 console.log 打印了 “sent heartbeat”，其实包根本没发出去——Charles 抓包才能验证。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
真实可行的做法是组合使用：
- 用
requestIdleCallback+setTimeout替代setInterval，降低后台执行优先级但保证至少触发一次 - 监听
document.addEventListener('visibilitychange', ...)，document.hidden === true时立即发心跳，并把下一次定时器延后到页面重新可见后 5 秒 - 心跳消息体必须带唯一
seq字段（如{"type":"ping","seq":123456}），方便服务端区分是否重复或乱序
服务端 pong 超时检测不能省略
常见错误是服务端收到 ping 就立刻回 pong，但完全不检查客户端有没有真正收到并响应。结果客户端网络卡顿，pong 发不出去，服务端还在等，连接堆在 CLOSE_WAIT 状态，最终耗尽文件描述符。
每个连接需维护独立状态：
- 收到
ping时，清空该连接的pong_received标志位，并启动一个setTimeout(..., 30000) - 收到客户端
pong时，置pong_received = true并清除定时器 - 定时器触发时若
pong_received === false，执行ws.close(4001, "pong timeout") - 注意：FastAPI / Node.js 的
ws.ping()方法只是发帧，不自动等待响应，必须手动补全逻辑
最容易被忽略的是：心跳不是单向“我活着”，而是双向“我们还能通”。客户端发 ping、服务端回 pong、客户端再确认 pong 被收到——这三步闭环做完，才算一次有效心跳。少任何一环，连接就只是看起来没断而已。
