websocket未显式close()必然导致内存泄漏，因tcp连接和js对象无法释放；事件监听器未解绑、心跳定时器未清除、全局单例缺乏销毁契约均会加剧泄漏。
WebSocket 未关闭，前端内存必然暴涨，不是“可能”，而是“一定”——只要页面不刷新，泄漏对象就持续累积，DOM、闭包、监听器全卡在内存里出不去。
WebSocket 实例未显式 close() 是最常见泄漏源头
很多人以为页面卸载（beforeUnmount 或 useEffect 清理函数）能自动回收 WebSocket，但事实是：只要没调用 ws.close()，底层 TCP 连接和关联的 JS 对象就不会释放。
- Chrome Memory 面板中搜索
WebSocket，能看到堆快照里不断新增的实例，且 Retainers 显示被闭包或全局数组强引用 - 即使连接已断开（比如网络中断），
ws.readyState === 0或3时，若没手动close()，实例仍驻留内存 - Vue/React 组件反复挂载卸载，每次新建
new WebSocket(...)却不清理旧实例，泄漏呈线性增长
事件监听器未解绑让整个组件无法 GC
ws.onmessage、ws.onerror 等直接赋值的回调函数，会形成闭包，隐式持有组件 this、ref、state 等上下文。只要监听器没置为 null 或移除，组件实例就永远无法被回收。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 错误写法：
ws.onmessage = (e) => this.handleData(e)—— 卸载时不设ws.onmessage = null，闭包一直活着 - 更隐蔽的问题：用
addEventListener包装 WebSocket 消息（如自定义事件总线），却只清空了事件总线 listeners 数组，忘了ws本身还挂着原始监听器 - 推荐做法：统一在
ws.onclose回调里执行ws.onmessage = null; ws.onerror = null; ws.onopen = null
心跳定时器未清除导致持续运行
为防网关超时断连，常加 setInterval 发送 ping。但这个定时器生命周期必须与 WebSocket 强绑定——连接关闭时，它必须立刻被 clearInterval，否则每秒都在触发闭包执行，拖着整个作用域不释放。
- 常见坑：把
heartbeatTimer存在组件 data / state 里，卸载时只清 state，没清 timer - 更稳妥做法：把 timer ID 存在 WebSocket 实例上（如
ws.heartbeatTimer = setInterval(...)），然后在ws.onclose里统一清理 - 注意：
clearInterval前要判空，避免重复调用报错；timer ID 被 GC 后不可恢复，所以不能依赖“下次重连再启”来掩盖问题
Vue3 / React 中全局 WebSocket 管理必须带销毁契约
所谓“全局 WebSocket 实例”，本质是单例 + 多组件订阅。一旦缺少明确的销毁入口，就等于给每个订阅者发了一张长期饭票，谁都不好意思先退席。
- 不要用匿名函数做监听器：
ws.addListener((data) => {...})—— 无法在卸载时精准removeListener - Vue3 推荐用
onBeforeUnmount触发connection.disconnect()，该方法内部必须包含：ws.close()、clearInterval(ws.heartbeatTimer)、ws.onmessage = null - React 中 useEffect 清理函数不能只写
return () => { /* 忘了 ws.close() */ }，必须确保所有资源释放动作都落在同一处，且顺序合理（先停心跳，再关连接，最后清监听）
真正难的不是写对那几行 close() 和 clearInterval()，而是在组件树层层嵌套、路由频繁切换、错误重连逻辑交织的情况下，保证每一次连接创建都有且仅有一次对应的销毁调用——漏掉一次，内存曲线就多一个台阶。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
