内存泄漏是前端应用中最隐蔽的性能问题之一。它不会立刻让页面崩溃，却会随着用户操作逐渐吞噬内存，最终导致页面卡顿、标签页崩溃。更麻烦的是，泄漏往往在开发阶段难以复现，只有长时间运行或高频交互后才暴露出来。本文将从常见泄漏场景出发，结合 Chrome DevTools 的实战操作，帮你建立一套可落地的排查思路。
为什么 JavaScript 中会出现内存泄漏
现代浏览器的垃圾回收机制基于「可达性」：从根对象（window、document、全局变量等）出发，无法通过引用链到达的对象会被回收。所谓内存泄漏，就是本该被回收的对象，因为某些意外的引用关系仍然可达，于是永远留在内存中。
理解这一点很关键——排查泄漏的本质，就是找到那些「不该存在的引用路径」。
常见的内存泄漏场景
1. 意外的全局变量
未声明的变量会挂到 window 上，除非页面关闭，否则不会被回收：
function processData() {
result = []; // 漏写 let/const，result 成为全局变量
// ...
}
在严格模式（'use strict'）下这类问题会直接报错，所以建议始终开启严格模式或使用 ES Module。
2. 被遗忘的定时器与回调
setInterval 如果没有在组件卸载时清除，其回调会一直持有对外部变量的引用：
mounted() {
this.timer = setInterval(() => {
this.fetchData(); // 持有组件实例引用
}, 1000);
}
// 忘记在 beforeUnmount 中 clearInterval(this.timer)
setTimeout、requestAnimationFrame 以及各类事件监听器都有同样的问题。
3. 未解绑的事件监听
在 window、document 或长期存在的 DOM 节点上添加监听器，却未在适当时机移除：
window.addEventListener('resize', this.handleResize);
// 组件销毁时没有 removeEventListener
尤其注意匿名函数形式的监听器——因为无法再次引用，根本没法移除。
4. 闭包持有大对象
闭包会保留其作用域链上的变量。如果闭包长期存活，被它引用的对象也无法释放：
function createHandler() {
const hugeData = new Array(1e6).fill('x');
return function () {
console.log(hugeData.length); // hugeData 一直被持有
};
}
5. DOM 引用残留
即使节点已从 DOM 树中移除，只要 JS 中还持有它的引用，它就依然占据内存：
const removed = document.getElementById('old');
document.body.removeChild(removed);
// removed 变量仍指向该节点，无法回收
6. 分离的 DOM 节点（Detached DOM）
这是最典型的泄漏形态：DOM 节点已从文档中脱离，但被 JS 引用，导致整棵子树都无法回收。常见于把节点存入数组或 Map 后忘记清理。
7. 控制台日志与缓存
console.log 打印的对象会被 DevTools 保留引用，开发时容易忽略。此外，无上限的缓存（Map、数组）也是常见隐患，应使用 WeakMap / WeakSet 或设置淘汰策略。
Chrome DevTools 实战排查
第一步：用 Performance 面板定位异常
打开 DevTools → Performance，勾选 Memory，录制一段包含反复操作（如打开/关闭弹窗）的时间线。观察 JS Heap 曲线：如果每次操作后内存阶梯式上升且不回落，就说明存在泄漏。
第二步：用 Memory 面板抓取堆快照
这是定位泄漏的核心工具。操作流程：
- 打开 Memory 面板，选择 Heap snapshot。
- 先执行一次会触发泄漏的操作，点击「Collect garbage」（垃圾桶图标）强制 GC。
- 拍摄快照 A。
- 再次执行同样的操作若干次，再次强制 GC，拍摄快照 B。
- 在快照 B 的视图下拉框中选择 Comparison，与快照 A 对比。
在对比结果中，重点关注 Delta 为正且持续增长的对象类型。展开后可以看到具体的引用链（Retainers），顺着链条就能找到「谁在持有它」。
第三步：识别 Detached 节点
在快照的筛选框输入 Detached，可以快速列出所有分离的 DOM 节点。如果数量随操作不断增加，基本可以确认是 DOM 引用泄漏。点击节点查看 Retainers 面板，就能看到是哪段代码在引用它。
第四步：用 Allocation instrumentation on timeline
这个模式可以按时间记录内存分配。适合观察「哪些函数在不断分配新对象却不释放」。录制后，蓝色竖条代表新分配，灰色代表已回收。如果某处只有蓝色没有灰色，就是泄漏点。
第五步：结合代码定位与修复
找到引用链后，回到源码中检查：
- 定时器是否在卸载时清除？
- 事件监听是否成对出现？
- 全局变量是否意外创建？
- 缓存是否有上限？
修复后重复上述快照对比流程，确认 Delta 归零或稳定。
预防胜于排查
与其事后排查，不如在编码阶段建立习惯：
- 组件卸载时统一清理定时器、监听器、订阅。
- 使用
AbortController管理事件监听和 fetch 请求的生命周期。 - 缓存使用
WeakMap，避免强引用。 - 避免在全局或长生命周期对象上挂载大对象。
- 在 CI 中加入内存回归测试，对关键交互做快照对比。
小结
内存泄漏排查的核心是「对比」与「追溯」：通过多次堆快照对比找出增长的对象，再顺着引用链追溯到持有它的代码。Chrome DevTools 的 Memory 面板提供了完整的工具链，配合对常见泄漏场景的敏感度，绝大多数问题都能被快速定位。养成清理副作用的编码习惯，才是从源头杜绝泄漏的根本办法。
未经允许不得转载：任鹏个人博客 » JavaScript 内存泄漏排查指南：常见场景与 Chrome DevTools 实战
