JavaScript闭包导致内存泄漏的常见场景

那么在实际开发中，哪些场景最容易触发闭包内存泄漏呢？下面列举几个常见的高风险场景。

事件监听器未解绑

事件监听器未解绑是闭包内存泄漏最常见的源头之一。当我们用闭包函数作为点击、滚动等事件的回调时，绑定完成后组件却被卸载，而 removeEventListener 却没有执行。如此一来，闭包连同它捕获的整个作用域——包括 DOM 节点、state、大型数组——全部被滞留在内存中无法释放。

• 在单页应用中，页面频繁切换，很容易积累大量未清除的监听器
• 异步加载后动态绑定的监听器尤其容易遗漏清理步骤
• 推荐采用统一管理策略：React 使用 useEffect 清理函数，Vue 使用 beforeUnmount 钩子，原生 JavaScript 则维护一个 listeners 数组来批量移除

定时器未清除

setInterval 或 setTimeout 的回调本质上都是闭包。只要定时器还在运行，回调中访问过的 this、DOM 元素、bigData 等资源就无法被垃圾回收器回收。

• 典型表现：路由跳转后控制台仍在打印日志，或者内存面板中的数字持续增长
• 务必在组件销毁或页面离开前调用 clearInterval/clearTimeout
• 另外，尽量避免让闭包直接引用大对象。必要时只传递一个 ID 或轻量字段进去，而不是整个数据结构

全局或长生命周期对象持有闭包

把闭包赋给 window、模块导出对象或 class 实例属性，相当于给它发了一张“永久居留证”。只要宿主对象不销毁，闭包和它捕获的所有变量就永远无法被回收。

例如缓存函数写成 cache[key] = () => doSomething(largeData)，largeData 就会被一直锁定。这种情况下，优先使用 WeakMap 来替代——当键对象被回收后，对应的缓存条目会自动失效。如果必须使用全局缓存，可以增加 TTL 过期机制，或者手动设为 null 来清理。

闭包捕获了不该捕获的大对象

一个轻量级的回调，因为写法松散，可能偷偷背负了整棵作用域树。比如在循环中使用 var 声明变量再传入闭包，所有闭包会共享同一个变量，不仅逻辑容易出错，还会延长整个作用域的生命周期。

多个闭包共享同一个外层作用域时，即使只使用了其中一个函数，所有被捕获的数据（config、cache、largeArray）也全都必须保留。优化方向很清晰：按需拆分闭包，用参数传值替代捕获，对大对象手动切断引用（比如设为 null）。在排序、搜索这类算法中，要避免在闭包中直接引用百万级数组，改用索引或 ID 间接操作。