WebSocket断连时on_close常不触发，因中间设备静默断开；应依赖socket.timeout等底层异常而非on_close，并配置合理ping_interval（如20秒）和ping_timeout（如3秒）来主动探测连接状态。
WebSocket连接突然断开，on_close却没触发？
这不是你的代码漏写了回调，而是网络层已经“静默失联”了——比如运营商NAT超时、云LB主动砍掉空闲连接、防火墙丢包，TCP连接卡在 ESTABLISHED 状态，但服务端早把 socket 关了。这时候靠监听 on_close 等重连，等于等一个永远不会来的通知。
- 真实断连信号往往来自底层：捕获
socket.timeout、OSError、ConnectionRefusedError，比等on_close可靠十倍 -
websocket-client的ping_interval=30是秒级单位（不是毫秒！），设成 30 意味着每 30 秒发一次 ping 帧；ping_timeout=5表示发完后 5 秒内没收到 pong 就抛WebSocketConnectionClosedException - 别信系统默认 TCP keepalive（通常 2 小时才生效），它对 WebSocket 完全无效
心跳间隔设成 30 秒，为什么还是频繁断连？
因为中间设备根本不看你的协议语义——CDN、Nginx、企业网关、甚至某些云厂商 LB，都有自己的空闲超时策略，常见值是 45–90 秒。你发 ping 的节奏必须比最短的那个阈值更激进。
- Nginx 默认
proxy_read_timeout=60，意味着后端 60 秒不发数据，它就直接断开连接；解决方案是调小ping_interval到 25 秒以内，或同步改 Nginx 配置 - 移动网络下，运营商 NAT 超时可能低至 30 秒；建议生产环境统一用
ping_interval=20、ping_timeout=3 - 服务端不回
pong？先用wscat -c wss://your.domain/ws手动连上，输入{"type":"ping"}看是否返回{"type":"pong"}，快速验证服务端行为
Python 用 websocket-client 实现带心跳的自动重连
这个库本身不自动重连，也不默认开心跳；必须显式配置，且参数名容易写错——比如写成 ping_interval_ms 或漏掉 ping_timeout，都会导致心跳形同虚设。
- 正确初始化：
ws = websocket.WebSocketApp(<br> "wss://example.com/ws",<br> on_open=lambda ws: print("connected"),<br> on_message=lambda ws, msg: handle_msg(msg),<br> on_error=lambda ws, err: print(f"error: {err}"),<br> on_close=lambda ws, code, reason: print("closed")<br>)<br>ws.run_forever(ping_interval=20, ping_timeout=3) - 重连不能只靠 try/except
WebSocketConnectionClosedException；要在主循环外加兜底逻辑，捕获socket.timeout后手动ws.close()再重建 - 重连前务必
time.sleep(1)，否则密集重试可能被服务端限流；指数退避可选，但至少别立刻重试
浏览器端 JS 心跳怎么写才不内存泄漏？
原生 WebSocket API 不暴露发送 ping 帧的能力，所以得用业务消息模拟心跳——但定时器管理稍有不慎，切页、销毁实例时没清理，就会越积越多，最终卡死页面。
- 心跳定时器必须绑定到连接实例上，且在
onclose和onerror中统一clearInterval(heartbeatTimer) - 不要在
onopen里直接setInterval(() => ws.send("ping"))；应先判断ws.readyState === WebSocket.OPEN再发，避免连接未就绪就狂塞消息 - 心跳消息内容建议用固定字符串如
"ping"，别用 JSON 序列化对象——服务端解析成本高，且易因字段缺失导致误判
