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 等规则，提前拦截隐式全局变量、未使用变量等常见泄漏诱因。

重点盯防的泄漏对象类型

在快照对比中，优先筛选这几类：

• Detached DOM tree：DOM 元素已从文档中移除，但 JS 仍通过事件监听器、闭包、变量引用等方式持有着它。
• Closure：闭包函数长期存活（如绑定在全局事件或定时器上），导致其外层作用域中所有变量无法释放，尤其当包含大数组、图片 blob 或整个 DOM 节点时。
• Timer & EventListener：在 Elements 面板右键检查元素 → “Event Listeners” 查看是否残留监听；用 clearInterval/clearTimeout 和 removeEventListener 检查对应清理逻辑是否执行。
• 全局变量（window 上的属性）：在快照中搜索 Window 构造函数下的对象，展开看是否有意料之外的长生命周期数据。

基本上就这些。不复杂但容易忽略——关键是养成“操作前后比快照”的习惯，而不是等页面卡死才去查。