Chrome DevTools Memory面板需通过多次堆快照对比差异识别内存泄漏,重点观察Constructor列中持续增长的对象类型,并利用Retainers面板追踪引用链定位根源。
直接打开 chrome://inspect → 选中页面 → 点击 Open dedicated DevTools for Node(如果是网页,用 F12 打开后切到 Memory 标签页)即可开始排查。关键不是点“Take heap snapshot”,而是要对比多次快照之间的差异。
常见错误是只拍一张图就找“最大的对象”,其实泄漏必须通过「增长趋势」识别:比如连续执行某操作 5 次,每次后拍一张快照,然后在 Summary 视图里用 Comparison 模式查看「新增但未释放」的对象。
Constructor 列中持续增长的类型,如 Closure、Array、Object,尤其注意带匿名函数或绑定上下文的 Closure
Retainers 面板会显示谁持有它——这是定位根源的关键,90% 的泄漏卡在这一步没往下钻Distance 值判断“深不深”,要结合 Retainer Path 看实际引用链是否本该断开console.memory 和 performance.memory 能信吗能查趋势,不能定位对象。这两个 API 返回的是 JS 堆总使用量(usedJSHeapSize),适合写自动化检测脚本,比如在测试中反复触发某功能并记录内存值:
setInterval(() => {
console.log(`Heap: ${performance.memory.usedJSHeapSize / 1024 / 1024} MB`);
}, 2000);
但它们无法告诉你哪个变量没被回收。更危险的是:performance.memory 在部分 Chrome 版本(如 115+)默认禁用,需启动时加参数 --enable-precise-memory-info,否则返回 undefined。
console.memor
y 是非标准 API,仅 Chrome/Edge 支持,Firefox 不可用不是“用了闭包就会泄漏”,而是「闭包意外捕获了大对象,且该闭包被长生命周期对象持有」。典型例子是给全局对象(如 window 或 document)添加监听器,但忘记 removeEventListener:
function setupHandler() {
const bigData = new Array(1000000).fill('leak');
document.addEventListener('click', () => console.log(bigData.length));
}
setupHandler(); // bigData 永远不会被 GC
另一个高危场景是定时器回调中引用 DOM 元素,而元素已被移除但 timer 还活着。
addEventListener 时尽量传具名函数,方便后续 removeEventListener;或使用 { once: true } 选项useEffect 或 mounted 里启的定时器、监听器,必须在 unmounted/useEffect cleanup 中清除Retainers 时,如果看到 Window → EventListener → Closure → 你的变量,基本就是它了能缓解,但不能替代正确设计。它们只解决「键为对象时的强引用问题」,对值本身无保护作用。
例如用 WeakMap 缓存 DOM 元素计算结果是安全的,因为当元素被移除,WeakMap 项自动消失;但如果你把一个大数组塞进 WeakMap 的 value 里,而这个数组又被其他地方强引用着,它照样不回收。
WeakRef + FinalizationRegistry 只用于通知“对象可能被回收了”,不能阻止回收,也不保证立刻触发回调WeakMap 是锦上添花,不是止血钳WeakRef 在 Safari 14.1+、Chrome 84+ 支持,旧环境需降级方案Retainers 路径里分辨出哪一环本该主动切断——有时候是业务逻辑里一次忘记解绑,有时候是框架底层引用没暴露出来,得结合代码上下文交叉验证。