JavaScript内存泄漏排查实录：从DevTools快照找出元凶

内存泄漏是前端开发中最隐蔽的敌人之一。它不像报错那样直接，却会在用户长时间使用页面后逐渐拖慢响应，甚至导致标签页崩溃。尤其在单页应用（SPA）中，组件频繁挂载与卸载，稍有不慎就会留下“幽灵”引用。最近我就接手了一个后台管理系统的性能问题：页面运行半小时后，内存占用从 80MB 飙到 600MB，操作明显卡顿。借助 Chrome DevTools 的内存快照，我最终揪出了元凶。下面还原整个排查过程。

内存泄漏的常见征兆

这个系统基于 React + Redux，用户会在一个表格页反复打开详情弹窗。测试同事反馈：“连续打开关闭弹窗 50 次，页面就卡得没法用了。” 打开任务管理器，发现内存曲线呈阶梯状上升，且手动触发 GC 后也降不下来。这基本可以断定存在泄漏：对象被意外持有，垃圾回收器无法回收。

第一次快照：建立基线

打开 DevTools 的 Memory 面板，选择“Heap snapshot”，点击录制。为了对比，我先在页面初始状态（弹窗从未打开）拍下第一张快照，称为 Snapshot 1。此时内存中主要是框架、路由、基础组件等常驻对象。快照通常较大，但不必细看，它的作用是作为参照。

复现操作后第二次快照

接下来，我手动打开详情弹窗，再关闭，重复 20 次。每次操作都会触发组件挂载和卸载。完成后，手动点击垃圾桶图标强制垃圾回收，然后拍下第二张快照 Snapshot 2。关键点：一定要在操作后触发 GC，否则临时对象会干扰判断。

对比快照，寻找增长点

在 Snapshot 2 的视图下拉框中选择“Comparison”，并与 Snapshot 1 对比。DevTools 会列出新增的对象。我按“Delta”排序，发现几个异常：

- `Detached HTMLDivElement` 数量增加了 40 个（每次弹窗产生 2 个？）
- 一个名为 `ModalComponent` 的闭包对象数量增加了 20 个
- `Array` 和 `Object` 也有大量增长，但比较分散

分离的 DOM 节点是典型信号——组件已经卸载，但 DOM 还被 JS 引用。闭包数量与打开次数完全吻合，说明每次弹窗都留下了一个未被释放的闭包。

定位到具体代码：一个未清理的定时器

选中 `ModalComponent` 闭包，查看下方的“Retainers”面板（引用链）。它显示这个闭包被一个 `setInterval` 的回调引用，而该回调又被一个 `Window` 对象持有。继续展开，发现 `setInterval` 的 ID 是 1234，对应的代码在 `ModalComponent` 的 `useEffect` 里：

useEffect(() => {
  const timer = setInterval(() => {
    // 轮询更新弹窗内的数据
    fetchData().then(data => setData(data));
  }, 5000);
  // 忘记写 return () => clearInterval(timer)
}, []);

问题很明确：弹窗关闭时组件卸载，但 `setInterval` 没有清除，回调持续运行，并通过闭包持有了组件内的 `setData`、DOM 引用以及整个组件作用域。每次打开弹窗都会创建一个新的定时器，内存自然只增不减。

修复与验证

在 `useEffect` 中补上清理函数：

useEffect(() => {
  const timer = setInterval(() => { ... }, 5000);
  return () => clearInterval(timer);
}, []);

同时，我还发现另一个隐蔽问题：某个全局事件监听器在组件挂载时添加，却未在卸载时移除。一并修复后，重新用同样的步骤拍摄快照对比，`Detached` 节点和闭包数量不再增长，内存曲线在 GC 后回落至基线水平。

快照排查的实用技巧

这次经历让我总结了几个要点：第一，快照要拍三次——操作前、操作后、再次操作后，用对比模式看增量；第二，优先关注 `Detached` 节点和闭包数量，它们往往直指泄漏源；第三，善用 Retainers 面板，它能展示完整的引用链，告诉你“谁在阻止回收”；第四，修复后务必用相同路径验证，确保内存不再阶梯上升。

内存泄漏排查并不神秘，它更像一场侦探游戏。DevTools 的快照就是你的放大镜，而对比功能就是你的时间线。只要耐心追踪引用链，元凶终会现形。下次遇到页面越用越卡，不妨先拍两张快照比一比——也许答案就在那里。