JS内存泄漏本质是“本该释放的对象仍被引用”，表现为内存阶梯式上涨、GC频繁无效、生命周期失配；需通过任务管理器、Performance、Heap Snapshot等工具链定位DOM引用、闭包、全局变量等五大高频泄漏源并修复。
JS 内存泄漏不是“会不会发生”的问题，而是“什么时候暴露”的问题。线上页面卡顿、标签页崩溃、Node.js 进程 OOM，背后往往就是几行没清理的监听、一个没释放的闭包、或一段被遗忘的全局引用。真正的专家级排查，不靠猜，而靠指标驱动、工具链协同、模式识别三者结合。
盯住三个铁律指标，30秒确认泄漏存在
别急着开 DevTools。先看是否真有泄漏：
- 内存阶梯式上涨：打开浏览器任务管理器（Shift+Esc），静置页面 20 秒，再重复执行同一操作（如打开/关闭弹窗）5 次；若每次操作后内存都比前一次高 8% 以上，且不回落，基本可断定泄漏
- GC 频繁但无效：在 Performance 面板录制 10 秒，若出现 ≥4 次 GC（黄色/灰色小块），且每次 GC 后内存下降＜5MB，说明大量对象因“意外引用”无法回收
- 生命周期失配：Vue/React 组件卸载后，对应 DOM 节点仍出现在堆快照中；或路由切换后，上一页的 ViewModel 实例 retain size 仍超 2MB，就是典型泄漏信号
用对工具链，3 分钟定位根因代码
堆快照不是翻字典，要带着假设去验证：
- Heap Snapshot 对比法：拍两次快照（操作前 + 操作后），筛选 Detached 查 DOM 泄漏、Array 查大数组、Closure 查闭包引用；重点看 “Retainers” 中是否出现 Global、Timer、EventListener
-
事件监听器速查：控制台输入
getEventListeners(document)，执行操作后再查，对比新增未移除的监听；尤其关注scroll、resize、message等高频事件绑定位置 -
定时器与观察者追踪：执行
console.log(Object.keys(globalThis).filter(k => /interval|timeout|observer/i.test(k)))，快速发现未清除的setInterval或MutationObserver实例
直击五大高频泄漏模式，精准修复
90% 的泄漏集中在以下场景，修复有固定范式：
-
DOM 引用未解绑：删除元素前，必须同步清理 JS 引用 ——
el.remove()不等于el = null；Map/Set 缓存 DOM 时，务必在 removeChild 后调用cache.delete(id) -
闭包捕获过大对象：避免在长生命周期函数（如事件处理器、定时器回调）中直接引用大数组或大对象；改用 ID 或轻量代理，或显式置空：
handler.largeRef = null -
全局变量污染：所有未声明变量（
a = []）都会挂到window下；启用严格模式 + ESLint 规则no-implicit-globals从源头拦截 -
定时器/观察者未销毁：组件卸载、模块解构时，必须执行
clearInterval(id)、observer.disconnect()；推荐封装成useDisposableHook 或cleanup()方法统一管理 -
第三方库副作用：地图、图表、富文本等库常内部持有 DOM 或缓存数据；查阅其文档的
destroy()或dispose()方法，确保调用；必要时用WeakMap替代强引用缓存
长期防控：从开发到上线的内存健康体系
专家级不止于修 bug，更在于建防线：
- CI 阶段接入
CoBOT SAST，静态扫描闭包大对象引用、未清除定时器、全局变量风险 - 本地开发启用
--trace-gc --trace-gc-verbose（Node.js）或 Memory 面板录制，把内存增长纳入日常调试流程 - 生产环境通过
heapdump（Node）或performance.memory（浏览器）定期上报内存水位，设置 >800MB 告警阈值 - 关键模块强制实现
dispose()接口，所有资源型对象（WebSocket、Worker、Canvas）遵循 “谁创建，谁释放” 原则
