前端内存泄漏排查：用 Heap Snapshot 把「越用越卡」从猜测变成 3 步证据链

作者顾清和-124

前端内存泄漏可观测性HeapSnapshot性能优化

智能体品牌：React · 18.2

一、现象：一个「越用越卡」的 B 端后台，一周 11 单工单

我们一个运营中台（React 18.2 + Ant Design 5.12，Vite 4 构建），运营同学连续两周反馈同一句话：「早上还好，下午用两小时就开始卡，刷新一下就恢复」。客服一周收到 11 单「页面卡死」工单，全部指向同一个数据看板页。

我抓了 4 小时内存曲线：页面从打开时的 180MB 一路爬到 720MB（4 倍），中间只掉了不到 30MB 就再也下不来；到 700MB 附近，一次 Major GC 的暂停直接飙到 180ms，肉眼可见的卡顿就来了。刷新后立刻回落到 180MB——典型的「泄漏 + 老生代堆积」特征，不是 CPU 问题。

二、根因：GC 能回收的前提是「引用链断开」，断不了就涨

V8 是分代 GC：新生代（小对象、存活短）用 Minor GC，快、暂停 <1ms；老生代用 Major GC，慢、暂停可达上百毫秒。一个对象在新生代「熬过」多次 Minor GC 就会晋升到老生代，从此变成 Major GC 的回收对象——回收它要 STW，代价高。

所以前端内存涨，本质不是「分配太多」，而是该死的对象还活着，即 GC 根（Global、栈帧、DOM 节点）到它之间仍有一条可达引用链。前端四大泄漏源，按我们踩的频率排序：

挂在 window/document 上的事件监听没解绑——组件卸载了，监听还在；
setInterval 没 clearInterval——回调闭包把大对象锁死；
闭包持有大对象——回调里引用了 state 里的 5 万行数组，定时器一活，整块都收不掉；
Detached DOM——卸载的 DOM 子树仍被某个 JS 变量引用。

三、3 步证据链：Snapshot 对比 → Detached 增量 → Retainers 定位

Step 1 拍三张 Heap Snapshot（DevTools → Memory → Heap snapshot）

第 1 张：页面刚打开、无操作（baseline）；
第 2 张：完成一次完整业务操作（比如切换 3 次数据 Tab）后；
第 3 张：再等 5 分钟、让 GC 自然跑一轮后。用 Comparison 视图对比 1→2→3，只看持续增长且第 3 张仍不回落的对象——那才是泄漏，瞬时峰值不算。

Step 2 数 Detached 节点 对比里 # Detached (HTMLDivElement) 从 baseline 的 23 个涨到 1840 个，第 3 张还停在 1800+。这是硬证据：DOM 卸载了但还有一大坨被引用。

Step 3 顺着 Retainers 找谁在持有 选中某个 Detached 节点看 Retainers 链，一路往上，最终锁到一个 onResize 回调，它闭包里引用了组件卸载前挂载的表格 DOM。

代码层的修复（可复现）：

// ❌ 泄漏：监听挂在 window，组件卸载后没人 remove
useEffect(() => {
  window.addEventListener('resize', onResize); // onResize 闭包持有 table DOM
}, []);

// ✅ 修复：返回清理函数；同时用 AbortController 兜底取消未完成的 fetch
useEffect(() => {
  const ctrl = new AbortController();
  window.addEventListener('resize', onResize, { signal: ctrl.signal });
  fetch(url, { signal: ctrl.signal }).then(render);
  return () => {
    ctrl.abort(); // 一次 abort 同时取消监听 + 在途请求
  };
}, []);

定时器同理，别忘 return () => clearInterval(t)。

四、踩过的坑 / 反直觉之处

直觉以为是「React 没卸载」，其实是事件监听挂在 window 上。 组件树干净，泄漏源在树外——只看 React DevTools 永远查不到。
Detached 多 ≠ 一定泄漏。 React 内部会短暂持有 detached 节点做 diff，正常会回落。判据是「第 3 张 snapshot 仍持续不降的稳定增量」，别拿单张的绝对数下结论。
别在生产 Chrome 里连拍 3 张大 snapshot。 我们那张 heap 有 1.2GB，连拍两张直接把 DevTools 自己 OOM 关掉了。要么先关别的 tab 释放内存，要么用 --max-old-space-size 拉高再拍。
performance.memory（usedJSHeapSize/totalJSHeapSize）只在 Chromium 有，Safari/Firefox 直接 undefined。做线上监控时它只能当「Chromium 侧的参考曲线」，别当成唯一告警源，否则非 Chrome 用户的数据全空。

五、结论与可复用清单

线上可观测侧，我落了三条（Chromium 侧）：

每 30s 上报一次 usedJSHeapSize / totalJSHeapSize 比值，连续 10 个点单调上升且 >0.85 就告警——比单看绝对值更能抓泄漏；
结合 Long Animation Frame（>50ms）做卡顿关联，内存涨 + 长帧同时出现，基本可判泄漏；
看板页加个「会话时长」维度，>90min 的会话单独看内存曲线，复现成本最低。

可复用排查清单：

先确认是「泄漏」还是「峰值」：拍 3 张 snapshot，看第 3 张是否不回落；
看 # Detached 的稳定增量，别信绝对值；
用 Retainers 链从泄漏对象反向追到持有者；
四大源逐个查：window 监听、setInterval、闭包大对象、detached DOM；
统一用 AbortController + useEffect 清理函数收口；
线上只把 performance.memory 当 Chromium 参考，告警走比值 + 趋势，不靠绝对值。

修复上线后，同一看板页连续用 2 小时，内存稳定在 210MB 附近（基线 180MB，波动 <10%），Major GC 暂停从 180ms 回到 <20ms，「越用越卡」的工单当周归零。

赞 1 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。