WebSocket连接后需主动发心跳，否则中间设备超时断连但readyState仍为1；重连逻辑须放onclose中并清理旧监听器，结合visibilitychange和健康检查避免重复消息与内存泄漏。
WebSocket连接后不发心跳，readyState 会卡在 1 却收不到消息
WebSocket本身不内置心跳机制，服务端通常靠客户端定时发 ping 或业务消息来判断连接存活。如果前端不主动发心跳，Nginx、CDN、云厂商LB（如阿里云SLB）或服务端的空闲超时（常见 60–300 秒）会直接切断 TCP 连接，但浏览器里 ws.readyState 仍显示 1（OPEN），后续 send() 会静默失败。
解决办法是：连接打开后立刻启动定时器，用 ws.send() 发一个轻量消息（比如 "ping"），或调用 ws.ping()（注意：该方法**未被所有浏览器支持**，Chrome 120+ 支持，Firefox 和 Safari 当前不支持，不能依赖）。
- 推荐用业务层心跳：发送 JSON 字符串
{"type":"heartbeat"}，服务端返回{"type":"pong"} - 不要用
setTimeout嵌套模拟间隔——用setInterval更稳，且要在onclose里clearInterval - 心跳间隔建议设为服务端超时时间的 1/2～2/3，比如服务端超时 120 秒，前端心跳设 45 秒
onerror 和 onclose 都触发了，但重连逻辑没跑起来
很多人把重连写在 onerror 里，结果发现断网时只触发 onclose，而 onerror 只在连接建立阶段失败（如 DNS 解析失败、跨域拒绝）才触发。真正连接已建好后的异常断开，基本只走 onclose。
另外，onclose 触发时，ws 实例已销毁，不能再调 ws.close() 或 ws.send()，否则报 InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 重连逻辑必须只放在
onclose回调里，且要判断event.code：非 1000（正常关闭）或 1001（离开页面）才考虑重连 - 加个重连次数限制和退避策略，比如第 1 次等 1s，第 2 次等 2s，第 3 次起固定 5s，避免雪崩式重连
- 用闭包变量（如
let reconnectTimes = 0）记录当前重连次数，别存在ws实例上——它马上就被 GC 了
重连时反复创建 WebSocket 实例，内存泄漏还触发多次 onmessage
没清理旧监听器就新建连接，会导致多个 ws 实例同时监听 onmessage，旧连接哪怕已断开，只要没手动移除事件，回调仍可能执行（尤其在弱网下延迟触发）。更糟的是，每个 ws 实例都持有对 this 或外部作用域的引用，长期不释放会造成内存堆积。
核心原则：每次新连接前，确保旧连接已 close() 并解绑所有事件。
- 封装一个
disconnect()方法：调用ws.close()+ws.onmessage = null+ws.onerror = null+ws.onclose = null - 不要用
addEventListener绑定事件（那样得记 handler 引用才能removeEventListener），统一用赋值式绑定 - 重连前先执行
disconnect()，再 new WebSocket，避免“双 ws 并存”
移动端切后台再切回来，ws.readyState === 0 却还在重连
iOS Safari 和部分安卓 WebView 在页面切后台时会冻结 JS 定时器，setInterval 暂停，心跳停止；切回来瞬间，多个被积压的定时器回调可能集中触发，导致并发重连。更麻烦的是，切后台期间连接其实已被服务端或中间设备断掉，但前端 ws.readyState 还是 0（CONNECTING）或 1（没人通知它）。
应对方式不是等定时器恢复，而是借助页面可见性 API 主动干预：
- 监听
document.visibilityState，visibilitychange事件中：若变为hidden，暂停心跳定时器（clearInterval）；若变为visible，先检查ws.readyState !== 1就立即重连，别等下一个心跳周期 - 额外加个“连接健康检查”：每 10 秒用
setTimeout检查一次ws.readyState是否为1，不是就主动 close + 重连——这能覆盖定时器失准的场景
onmessage 导致消息重复处理——这两处一出问题，用户就会看到“一条消息弹两遍”或者“怎么连了十几次”。 
