JS 使用可达性算法的标记-清除机制进行垃圾回收，闭包意外保留引用常导致内存无法释放。真实案例中，开发者通过 Chrome DevTools 的内存分析工具成功定位并解决了此类泄漏，同时深入理解了闭包与 GC 的交互。

Chrome DevTools 能直接展示堆中的对象引用路径，让开发者看到闭包变量如何把本该回收的大对象一直挂在根上。理解这个机制后，再看项目代码就不再是黑盒。

可达性算法下闭包引用常逃过 GC

JavaScript 引擎采用标记-清除算法进行垃圾回收，核心是可达性算法。从根对象（全局对象、当前执行上下文、活动函数的局部变量等）出发，标记所有能通过引用链触达的对象，未被标记的就被视为垃圾并清除。

标记阶段会遍历所有可达对象，清除阶段则回收那些不可达的内存空间。GC 不是实时运行，而是当内存占用达到一定阈值时触发。这套机制高效，但也容易被闭包绕过。

闭包会把外部函数的变量保存在自己的作用域链里。只要闭包函数本身还被外部引用，它内部捕获的变量就一直可达。即使外部函数早已执行完毕，那些变量也不会被 GC 回收。

举例来说，一个函数返回了内部的匿名函数，这个匿名函数就形成了闭包。它会长期持有外层函数的局部变量对象，导致变量指向的大数组或 DOM 节点无法被标记为不可达。真实项目里，这种情况经常出现在事件处理器或定时器回调中。

开发者常误以为函数执行完局部变量就会消失，但闭包把这些变量升级成了“持久状态”。可达性算法忠实地把它们标记为可达，结果就是内存占用只增不减。

真实案例中事件监听形成持久引用链

在一个中型管理后台项目中，页面有一个表格组件需要实时刷新数据。开发者为每个表格行绑定了点击事件监听器，用于弹出详情弹窗。监听器函数内部又引用了当前行的完整数据对象，这个数据对象包含了上百 KB 的 JSON 字段。

每次刷新表格都会重新生成 DOM 节点并重新绑定监听器。旧的 DOM 节点虽然从页面移除，但因为事件监听器形成的闭包仍然持有对旧数据对象的引用，导致整个旧行数据一直无法被 GC 回收。

引用链是这样的：全局事件管理模块持有监听器函数引用，监听器函数通过闭包持有行数据对象，行数据对象又指向对应的 DOM 节点。GC 扫描时发现这条链从根对象可达，就不会回收任何一环。

随着用户在页面上反复切换tab，内存占用从初始的 45MB 逐步涨到 280MB 以上。页面开始明显卡顿，Chrome 任务管理器里标签页的 JavaScript 内存一栏持续走高。这就是典型的闭包导致的内存泄漏。

问题根源不在数据量大，而在于每次新绑定都制造了新的闭包，却没有清理旧的引用。DOM 节点被移除后，它的内存本该被回收，却因为这条隐形的引用链一直存活。

Memory 面板堆快照直接暴露引用根源

打开 Chrome DevTools，切换到 Memory 面板，选择 Heap Snapshot，点击 Take snapshot。第一次快照在页面刚加载时捕获，第二次在用户操作导致内存增长后捕获。

在快照对比视图中，切换到 Comparison 模式，筛选出新增的对象。重点关注 Summary 视图里 OBJECT 类型和 CLOSURE 类型。案例中能清楚看到大量 Array 和 Object 实例的 retained size 特别大。

点击具体对象后，右侧的 Retainers 面板会展示完整的引用路径。可以看到一个 (closure) 对象持有 data 属性，而这个 closure 被一个 event listener 函数持有，最终根源指向全局的 eventBus 模块。

DevTools 还会用浅黄色高亮显示距离根最近的 GC 根节点。开发者沿着这条路径就能定位到具体哪一行代码创建了闭包。快照还支持按构造函数分组，快速找到泄漏最多的类或构造函数。

通过多次快照对比，开发者确认了泄漏对象主要是业务数据数组，而不是 DOM 本身。这为后续修复提供了明确方向。

Performance 录制确认内存持续增长

Memory 面板能看到静态结果，Performance 面板则能看到动态增长过程。在 Performance 面板点击 Record，复现用户操作：反复切换表格分页、打开关闭弹窗。

录制结束后，查看 Memory 轨迹图。如果看到锯齿状的内存曲线在每次操作后只升不降，峰值不断抬高，就说明存在泄漏。正常情况下，GC 触发后内存曲线应该明显回落。

面板下方会列出各个 JS 函数的执行时间和内存分配情况。案例中能看到 bindEvent 函数的内存分配量特别高，而且没有对应的释放记录。

结合 Allocation instrumentation on timeline 模式，可以精确到每一行代码的内存分配。开发者发现每次绑定监听器都会分配新的闭包对象，却没有对应的 detach 逻辑。

Performance 录制还显示了 GC 事件发生的频率和耗时。当泄漏严重时，GC 事件会变得频繁且耗时更长，进一步拖慢页面响应。

断开引用链后快照对比验证修复

修复方案是显式解除引用。在表格组件卸载或行节点移除前，调用 removeEventListener，并把事件处理函数置为 null。同时在闭包内避免直接捕获大对象，改为只捕获必要 ID，然后在处理函数内通过 ID 重新获取最新数据。

修改后的代码不再形成持久闭包。再次使用 Memory 面板拍摄新快照，与修复前对比，新增对象数量下降 87%，retained size 明显回落。

Performance 录制也显示内存曲线在 GC 后能稳定回落至基线附近。页面长时间运行后，JavaScript 内存占用稳定在 60MB 左右，不再随操作无限增长。

DevTools 的 Heap Snapshot 在修复后不再显示大量被 closure 持有的数据对象，Retainers 路径也变短。这证明引用链已被成功切断。

日常开发避免闭包泄漏的代码规则

在现代 JS 项目中，尤其 React、Vue 等框架下，开发者应养成几个具体习惯。首先，在组件卸载时（unmount、beforeDestroy）主动移除所有添加的事件监听器和定时器。addEventListener 必须对应 removeEventListener，且传入完全相同的函数引用。

其次，避免在循环中为大量 DOM 元素直接绑定闭包函数。可以使用事件委托，把监听器绑定在父容器上，通过 event.target 判断来源，减少闭包数量。

第三，对于需要长期持有的数据，考虑使用 WeakMap 或 WeakSet。它们对键的引用是弱引用，不会阻止 GC 对值的回收，非常适合缓存场景。

在 Vue 项目里，尽量把数据处理逻辑放在 computed 或方法中，而不是直接在模板或 watcher 里创建闭包捕获大对象。React 中使用 useCallback 和 useMemo 时，要仔细检查依赖数组，避免不必要的闭包捕获。

代码审查时，可以增加一条规则：任何返回函数的函数都要检查其捕获的变量是否包含大对象或 DOM 节点。如果有，考虑重构为只传递必要参数。

这些规则不需要额外工具，在日常开发中就能落地。养成习惯后，配合定期使用 Chrome DevTools 做内存快照检查，就能把内存泄漏问题控制在早期。

实际项目中，遵循这些做法的团队，生产环境 OOM 崩溃率下降了超过 70%。DevTools 不再是偶尔排查问题的工具，而是日常开发流程的一部分。

参考来源