websocket未显式close()必然导致句柄与内存双泄漏，需在组件卸载时调用destroy()清理定时器、事件监听器并关闭连接，服务端也须及时释放fd。
WebSocket长连接必然占用内存和句柄，不优化就一定会泄漏——这不是配置问题，而是资源生命周期没对齐。
WebSocket未显式close()导致句柄与内存双泄漏
只要没调用ws.close()，底层TCP连接就不会释放，操作系统文件描述符（FD）持续累积，JS对象也卡在堆里无法GC。Chrome Memory面板搜索WebSocket，能看到堆快照中不断新增的实例，且Retainers显示被闭包或全局数组强引用。
- 即使
ws.readyState === 0（CONNECTING）或3（CLOSED），只要没调ws.close()，实例仍驻留内存 - Vue/React组件反复挂载卸载，每次
new WebSocket()却不清理旧实例，泄漏呈线性增长 - 错误写法：
ws.onmessage = (e) => this.handleData(e)，卸载时不设ws.onmessage = null，闭包一直活着
心跳定时器未清除引发持续闭包驻留
为防网关超时断连而加的setInterval，若生命周期没和WebSocket强绑定，就会拖着整个作用域不释放——每秒触发一次，闭包里的this、ref、state全被锁死。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 常见坑：把
heartbeatTimer存在组件data/state里，卸载时只清state，没调clearInterval - 稳妥做法：把timer ID存到
ws.heartbeatTimer = setInterval(...)，然后在ws.onclose里统一clearInterval(ws.heartbeatTimer) - 务必判空：
if (ws.heartbeatTimer) clearInterval(ws.heartbeatTimer)，避免重复调用报错
全局单例管理必须带销毁契约
所谓“全局WebSocket”，本质是单例，但单例不等于永不销毁。没有销毁入口，就等于放任所有监听器、定时器、上下文对象长期驻留。
- 不能依赖
beforeUnmount或useEffect清理函数自动回收——它们不触发ws.close() - 推荐暴露
destroy()方法，内部执行：ws.close()+ws.onmessage = null+ws.onerror = null+clearInterval(ws.heartbeatTimer) - Vue3组合式API中，应在
onBeforeUnmount里显式调用该destroy()，而非寄希望于“组件卸载即释放”
服务端句柄耗尽的典型表现与定位
PHP/Node.js/Rust服务运行一段时间后拒绝新连接、日志频繁报EMFILE或Too many open files，基本可判定是FD泄漏——不是连接数太多，而是该关没关。
- PHP用Swoole时，必须在
onClose回调里手动unset($this->connections[$fd])或$server->close($fd) - Node.js用ws库，检查是否漏了
ws.terminate()或ws.close()，尤其在error和pong超时分支 - Rust用
tungstenite或axum-websockets，确认DashMap等注册表是否在断连后.remove()，避免Arc强引用循环
最易被忽略的一点：前端页面没刷新，但WebSocket实例已断开（比如网络切换），此时ws.readyState可能卡在0或2，既不触发onclose也不触发onerror，却仍在内存里占着位置——必须加心跳超时兜底，主动close()并重置状态。
