前端检查内存泄露完整示例

前端应用的内存泄露，说白了就是那些不再使用的内存没有被系统回收，导致页面占用的内存像滚雪球一样越滚越大。轻则页面卡顿、加载变慢，重则浏览器直接崩溃——这在单页应用（SPA）里尤其要命，因为路由频繁切换，但内存却迟迟不回收，问题会被无限放大。

举个例子，用户长时间使用某个后台管理系统，你会发现操作响应越来越迟钝，到最后只能强制刷新才能恢复正常。这十有八九，就是内存泄露在背后“捣鬼”。

一. 前端常见的内存泄露场景

先来看几个最容易踩坑的场景：

1. 意外的全局变量——比如你写了个a = 10，而不是let a = 10，这个变量就直接挂到了window上。页面不刷新，它就永远赖着不走。

2. 闭包滥用——闭包会牢牢地抓住外部作用域的引用不放。如果闭包里长期持有 DOM 或大型对象，内存就彻底回收无望了。最常见的就是事件监听回调里引用了大对象，却忘了清理。

3. 未清理的 DOM 引用——你手动删掉了某个 DOM 节点，但代码里还保留着它的引用（比如 let el = document.getElementById('test')），删除节点后也没把 el 置为 null。结果呢？这个节点虽然从页面上消失了，但内存里它还活着。

4. 定时器 / 事件监听未销毁——setInterval 用了却不用 clearInterval 清除，addEventListener 绑了却不用 removeEventListener 解绑。这在组件挂载/卸载的场景里尤其容易遗漏，而且后果相当隐蔽。

5. 第三方库 / 插件残留——某些第三方库（比如图表库、播放器）用完之后，如果没调用它们的销毁方法，内部资源就一直在那“挂着”，谁也拿不走。

6. 数组 / 对象无限增长——全局缓存对象没有设置过期机制，或者数组一直 push 数据，但从不清理无效项。内存就是这么一点一点被吃掉的。

二. 核心工具: 浏览器开发者工具 (Chrome DevTools)

1. 第一步: 复现内存泄露场景

要定位问题，首先得稳定地复现泄露行为。比如：

• SPA 中反复切换路由（A→B→A→B）；
• 点击按钮触发某操作（比如打开弹窗再关闭）；
• 长时间滚动或不断轮询请求数据。

2. 第二步: 用 Performance 面板初步确认

打开 Chrome 开发者工具，切到 Performance 面板。录制一段操作过程，看看内存曲线：

• 如果曲线持续上升，操作停止后也不回落——大概率有泄露。
• 如果曲线能在操作后回到初始水平——说明内存正常回收，问题不大。

3. 第三步: 用 Memory 面板精准定位

Performance 确认了有泄露之后，就该 Memory 面板上场了——它能告诉你“哪些对象还赖在内存里没走”。

Memory 面板支持三种快照类型，按需选择：

• Heap snapshot（堆快照）：捕获当前所有对象的快照，适合对比不同快照的差异，定位未回收的对象；
• Allocation instrumentation on timeline（时间线分配记录）：实时记录内存分配过程，适合观察某操作期间的内存分配细节；
• Allocation sampling（分配采样）：低开销的采样方案，适合快速排查大面积泄露，不需要精确到单个对象。

堆快照对比操作流程：

1. 打开 DevTools → 切换到「Memory」面板；
2. 选择「Heap snapshot」，点击「Take snapshot」拍摄初始快照（记为快照 1）；
3. 执行一次泄露复现步骤（比如切换一次路由）；
4. 再次点击「Take snapshot」拍摄快照 2；
5. 重复复现步骤 N 次（比如再切换 3 次路由），拍摄快照 3；
6. 在 Memory 面板左侧的快照列表中，选择快照 2 或 3 的下拉框，选择「Comparison」（对比），并与快照 1 对比。

这时候，哪些操作多占了内存、哪些对象没被回收，一目了然。

堆快照就像相机一样，能记录当前页面的堆内存情况。每快照一次，就产生一条记录。你可以随时点开看当时所有变量的结构和占比。

上图就是：先拍了一次快照，记录堆内存占用 59.4MB；然后操作页面之后又拍一次，变成了 59.7MB。点开对应记录，就能看到所有变量的详细信息。

录制过程中，右上角会有蓝色和灰色的柱形图。蓝色表示当前时间线正在占用的内存；灰色则代表之前占用的内存已经被释放。

用 Allocation on timeline 来观察也很直观：

三. 实用示例

1. 闭包使用不当引起的内存泄漏

来看一个典型的闭包陷阱。在 fn1 函数里定义了一个大数组 a，然后把它返回并赋值给了全局变量 res。虽然 fn1 执行完了，按理说变量 a 应该被回收，但因为 res 还拿着它的引用，所以 a 一直占着内存。这就是闭包使用不当。

执行fn1函数

用 Performance 录制一下：每次点击按钮，JS Heap 曲线就阶梯式上升。触发垃圾回收后，曲线比基准线高出不少——这基本就能判断有内存泄露了。

再用 Memory 的 Allocation instrumentation on timeline 确认一下：

录制时每次点击按钮，都能看到蓝色柱形（内存分配），但即便触发垃圾回收后，这些蓝色柱形也始终没变成灰色——说明分配的内存根本没被释放。

接下来用 Heap snapshot 定位问题：先拍一次快照，多次点击按钮后再拍一次，对比两张快照的内存变化。从 1.2 MB 涨到 1.7 MB，然后选择 Object allocated between Snapshot1 and Snapshot2，就能看到哪些对象是新分配且没被回收的——Array 的占比很高，那基本就是它了。

这就是用闭包导致泄露并定位问题的完整思路。

2. 全局变量

全局变量一般不会被垃圾回收，当然不是说所有全局变量都不能存在，只是一不小心就会把本该局部化的东西“流失”到全局。比如：

function fn1() {
  // 变量name未声明就直接赋值
  name = new Array(99999999)
}
fn1()

这时候全局就多了一个 name，它抱着一个巨大的数组，谁也动不了它。解决办法也很简单：注意规范声明，或者干脆开启严格模式，让这种错误在开发阶段就暴露出来。

3. 分离的 DOM 节点

假设你手动移除了某个 DOM 节点，但代码里还保留着对它的引用——这就是分离的 DOM 节点。来看一段经典代码：

  
我是子元素
  移除

点击按钮后，虽然页面上的 .child 确实被移除了，但全局变量 child 还拿着它的引用，所以这个节点的内存无法被释放。用 Memory 的快照功能来检测：先拍一次初始快照，点击移除后拍第二次，然后在筛选框里输入 detached，所有游离的节点就都列出来了。

解决办法很简单：将对 .child 节点的引用放到点击事件的回调函数里去，这样移除节点后，引用自然消亡，内存也就被回收了。

  
我是子元素
  移除

改动很小，但效果显著——节点在被移除的同时，引用也随之清除，内存泄露就此解决。

4. 控制台打印

这一点可能出乎很多人意料——console.log 也可能导致内存泄露。来看代码：

按钮

用 Performance 录制一下：

JS Heap 曲线阶梯式上升，最终远高于基准线——说明每次点击创建的 obj 都被 console.log 锁定了，无法回收。把 console.log 注释掉再试一次：

按钮

没有了 console.log，每次创建的 obj 瞬间被销毁，内存曲线稳稳地回到了基准线。所以，生产环境里最好不要留太多打印语句——尤其是打印大对象的时候。

5. 遗忘的定时器

定时器是一个很容易被忽视的“内存钉子户”。来看这个例子：

开启定时器

点击按钮后，fn1 执行完毕，应该退出了。但 setInterval 的回调函数还引用了 largeObj，而且定时器永远不会被清除——所以 largeObj 占着内存不走。

用 Performance 录制后发现曲线确实比基准线高，再用 Memory 的动态分配记录一看：每次点击按钮都有一个蓝色柱形出现，而且永远不会变成灰色——这就是内存泄露的铁证。

解决方法：如果只需要定时器执行三次，那就加一个计数器，执行完三次后清除定时器：

开启定时器

再录制一次，Memory 的动态记录显示：点击按钮后出现蓝色柱形（分配内存），3秒后定时器被清除，蓝色柱形变成了灰色柱形——内存被成功回收了。

结论很明确：学会正确使用 DevTools 的 Performance 和 Memory 面板，再加上对这些常见场景的敏感度，绝大部分前端内存泄露问题都能被轻松拿下。