JavaScript内存泄漏检测核心是确认“该回收的对象没被回收”，关键在于识别本该消失却持续驻留的对象；Chrome DevTools Memory面板提供堆快照、内存分配时间线和Performance+Memory三种视图，配合手动GC、WeakMap、heapdump、ESLint等手段，重点排查detached DOM、closure、timer/EventListener及全局变量。
JavaScript内存泄漏检测核心是确认“该回收的对象没被回收”。关键不在于看内存用了多少，而在于识别那些本该消失却持续驻留的对象。
Chrome DevTools Memory 面板是最直接的工具
它提供三种互补视图，配合使用效果最好：
- 堆快照（Heap Snapshot）：操作前拍一张，执行疑似泄漏行为（如打开/关闭弹窗、切换路由）后再拍一张，对比 Delta 列。重点关注 Retained Size 大、数量持续增长的对象，尤其是带 (detached) 标记的 DOM 节点、Closure、Array 或自定义构造函数实例。
- 内存分配时间线（Allocation Timeline）：开启 “Allocation instrumentation on timeline”，录制用户交互过程。蓝色柱状图代表新分配但未被回收的对象。长时间存活的蓝色块，往往对应闭包持有或全局引用未释放。
- Performance 面板 + Memory 复选框：录制一段典型操作（比如反复进入退出某页面），观察 JS Heap 曲线。如果每次操作后曲线只升不降，或下降幅度远小于上升幅度，基本可判定存在泄漏。
辅助排查手段与工具
单靠 DevTools 不够时，这些方法能补位：
-
手动触发垃圾回收：在 Memory 面板点击垃圾桶图标，或在控制台输入
if (global.gc) global.gc()（需 Node.js 启动加--expose-gc）。触发后若对象仍存在，说明有活跃引用链阻止回收。 -
WeakMap / WeakSet 替代强引用：不是检测工具，但能预防泄漏。例如缓存 DOM 元素时，用
const cache = new WeakMap()，元素被移除后自动失效，无需手动清理。 -
Node.js 环境用 heapdump：安装
npm install heapdump，代码中调用heapdump.writeSnapshot()生成 .heapsnapshot 文件，再用 Chrome DevTools 打开分析。 -
ESLint 静态检查：启用
no-unused-vars、no-undef、no-global-assign等规则，提前拦截隐式全局变量、未使用变量等常见泄漏诱因。
重点盯防的泄漏对象类型
在快照对比中，优先筛选这几类：
立即学习“Java免费学习笔记（深入）”；
- Detached DOM tree：DOM 元素已从文档中移除，但 JS 仍通过事件监听器、闭包、变量引用等方式持有着它。
- Closure：闭包函数长期存活（如绑定在全局事件或定时器上），导致其外层作用域中所有变量无法释放，尤其当包含大数组、图片 blob 或整个 DOM 节点时。
-
Timer & EventListener：在 Elements 面板右键检查元素 → “Event Listeners” 查看是否残留监听；用
clearInterval/clearTimeout和removeEventListener检查对应清理逻辑是否执行。 -
全局变量（window 上的属性）：在快照中搜索
Window构造函数下的对象，展开看是否有意料之外的长生命周期数据。
基本上就这些。不复杂但容易忽略——关键是养成“操作前后比快照”的习惯，而不是等页面卡死才去查。
