websocket断开后需心跳探测、状态隔离与资源清理来安全重连；onclose常不触发因中间设备静默断连；心跳间隔应小于链路最短空闲超时（如20秒）；重连前须清除定时器和事件监听器；send消息应入队缓存，重连后重发。
WebSocket连接断开后自动重连，不能靠反复调用 new WebSocket() 硬重启，必须配合心跳探测、状态隔离和资源清理——否则会积累定时器、重复绑定事件、触发多次重连请求，最终压垮客户端或服务端。
onclose 为什么经常不触发？
网络中间设备（如 Nginx、云 LB、运营商 NAT）静默断开连接时，TCP 层可能仍处于 ESTABLISHED 状态，但服务端已关闭 socket。此时浏览器收不到 FIN 包，onclose 永远不会执行。
- 真实断连信号往往来自底层异常：比如
socket.timeout、ConnectionRefusedError或心跳超时 -
readyState === WebSocket.CLOSED也不能作为唯一判断依据——闪断时它可能还维持为1（OPEN），但实际发不出消息 - 必须主动探测：靠客户端定时发
{"type":"ping"}，并等待服务端回{"type":"pong"}，超时即判定失效
心跳间隔怎么设才不被中间件砍掉？
心跳不是越勤越好，而是要比所有中间链路中最短的空闲超时阈值更激进。Nginx 默认 proxy_read_timeout=60，移动网关常见 30 秒，CDN 可能是 45 秒——你的心跳间隔必须小于其中最小值。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 生产环境推荐：
ping_interval=20秒（客户端发 ping），ping_timeout=3秒（等 pong 响应） - 服务端必须真正响应
pong；用wscat -c wss://your.domain/ws手动测试，输入{"type":"ping"}看是否返回{"type":"pong"} - 别依赖浏览器原生 Ping/Pong 控制帧——JS API 不暴露发送接口，只能用业务消息模拟
重连时如何避免定时器堆积和事件重复绑定？
每次重连前，必须彻底清理上一次连接残留，否则 setInterval 和 addEventListener 会越积越多，造成内存泄漏和逻辑错乱。
- 清理动作必须包含：
clearInterval(this.pingInterval)、clearTimeout(this.heartbeatTimeout) - 移除旧
WebSocket实例的所有监听器：用具名函数定义onopen/onmessage，再显式调用ws.removeEventListener('message', handler)；或直接弃用旧实例，新建一个 - 进入
RECONNECTING状态后，应忽略新的重连请求（比如用户狂点“重连按钮”） - 重连延迟要用指数退避：
delay = Math.min(2 ** retryCount * 1000, 30000)，避免雪崩式重试
send() 在断连期间发的消息怎么不丢？
业务层调用 send(data) 时，连接可能尚未建立或已中断。不能直接报错或丢弃，而应缓存待发队列，等重连成功后再批量重发。
- 维护一个
this.sendQueue = []，在readyState !== WebSocket.OPEN时推入数据 - 重连成功后（
onopen触发），遍历队列逐条调用ws.send()，并清空队列 - 注意：若服务端有消息幂等性保障，可放心重发；否则需加序列号或去重逻辑
- 队列长度建议设上限（如 100 条），超限时 warn 并丢弃老消息，防内存失控
最易被忽略的点是：心跳超时判定必须和服务端响应强绑定，不能只靠客户端定时器倒计时；重连必须销毁旧 WebSocket 实例，复用会导致事件监听器错位、send() 发到已关闭连接上而静默失败。
