WebSocket未关闭必然导致内存泄漏，因TCP连接、JS对象、闭包、定时器及事件监听器均无法释放；需通过堆快照、Retainers分析、事件属性检查、定时器清理和映射表删除等手段全面排查。
WebSocket 未关闭是前端内存泄漏的确定性源头——不是“可能泄漏”，而是“一定泄漏”。只要没调用 ws.close()，底层 TCP 连接、关联的 JS 对象、闭包上下文、定时器和事件监听器就全部卡在内存里无法释放。
看堆快照里 WebSocket 实例是否持续新增
打开 Chrome DevTools → Memory 面板 → 先点小垃圾箱图标强制 GC → 再点击 “Take heap snapshot” 拍摄快照。切换到 Summary 视图，输入 WebSocket 过滤：
- 若看到多个
WebSocket构造函数实例，且数量随页面跳转/组件反复挂载而增长，说明旧连接未销毁 - 点击任一 WebSocket 实例 → 查看右侧 Retainers 栏：若显示被
Closure → Component.this → state/ref/cache强引用，就是闭包钉住了整个组件 - 对比两次快照（如进入模块前 vs 关闭模块后），用 Comparison 模式筛选 “Objects allocated between snapshots”，重点关注 WebSocket 和 Closure 类型的 Delta 值是否为正且递增
查 onmessage/onclose 是否仍为函数而非 null
WebSocket 是 EventTarget，它的事件属性若仍指向函数，就代表监听器未解绑，闭包持续存活：
- 在控制台执行
console.dir(ws)，展开查看onmessage、onerror、onclose的值；若不是null或undefined，而是箭头函数或匿名函数，说明未清理 - 选中该 WebSocket 对象 → 切换到 Elements 面板 → 执行
getEventListeners(ws)，检查返回对象中是否有残留监听器 - 错误写法：
ws.onmessage = e => this.handle(e)，卸载时只做了ws.onmessage = null，但this.handle可能被其他地方强引用，导致this实例无法释放
验心跳定时器是否漏清
setInterval 是最隐蔽的驻留源，它让整个闭包环境无法被 GC：
立即学习“Java免费学习笔记（深入）”；
- 搜索代码中所有
setInterval调用点，确认每次ws.close()后是否同步调用了clearInterval(heartbeatId) - 更稳妥做法：把 timer ID 存在 WebSocket 实例上，如
ws.heartbeatTimer = setInterval(...)，然后在ws.onclose回调里统一执行clearInterval(ws.heartbeatTimer) - 在控制台运行
console.memory，反复触发连接建立 → 关闭 → 等待 10 秒 → 再查totalJSHeapSize；若数值不回落甚至持续上涨，大概率有定时器漏清
确认全局单例或映射表是否未 delete 条目
使用 Map / WeakMap / 全局数组管理 WebSocket 实例时，容易忽略条目清理：
- 检查是否用类似
socketMap.set(id, ws)注册了连接，但在ws.onclose或组件卸载时没执行socketMap.delete(id) - WeakMap 并不能自动解决这个问题：只要 Map 的 key（比如某个对象）还被其他地方强引用，value 就不会被回收；必须主动
delete或清空引用 - Vue/React 中若封装了全局 WebSocket 管理器，需确保提供明确的销毁方法（如
destroy()），并在组件 unmount 时调用
