JS 闭包内存泄漏：别让它悄悄拖垮你的页面

接手一个老项目，有时候会遇到个怪现象：页面打开没问题，功能也能跑通，可用户连续操作十几分钟后，浏览器明显变卡，甚至直接崩溃。没有控制台报错，代码逻辑也没报错，这时候大概率不是算法复杂度问题，而是内存泄漏在作祟。尤其是涉及闭包的场景，往往是最隐蔽的“杀手”。

咱们常把闭包当作保护私有变量的利器，但它本质上是在保留对外部作用域的引用。只要闭包还活着，它内部引用的那些大对象就无法被垃圾回收机制（GC）释放。如果不小心，这些本该被清理的对象就会一直堆在内存里，像背着越来越重的包袱爬山，走到最后自然喘不过气。

事件监听里的“隐形钩子”

最常见的泄漏点往往藏在 DOM 操作上。想象一下，你在某个函数或类实例中绑定了一个事件监听器，而这个监听器内部引用了 this 或者外部的大对象。

function setupListener() {
    const bigData = new Array(100000).fill('data'); // 假设这是个大数据量对象
    element.addEventListener('click', () => {
        console.log(bigData.length);
    });
}

这段代码看起来没什么，但一旦 setupListener 执行完毕，bigData 本该随着函数栈销毁。然而因为箭头函数是个闭包，它抓住了 bigData 的引用，导致即便元素被移出了 DOM，bigData 也回不去。

解决这个问题的核心思路只有一条：解除关联。如果是在组件化开发中，务必在组件销毁的生命周期（如 beforeDestroy 或 useEffect 的 cleanup）里调用 removeEventListener。这里有个易错点：如果你绑定的是匿名函数，移除时无法精准定位。建议将监听函数单独命名，或者用变量存储回调函数的引用，这样在清理阶段才能准确找到并解绑。

定时器与异步任务的陷阱

另一个重灾区是 setInterval 或 setTimeout。很多开发者习惯了在循环里设置定时器处理业务，却忘了在页面跳转或模块卸载时进行清理。

// 错误示范
let timer = setInterval(() => {
    processData(); 
}, 1000);

如果这个定时器被放在一个复杂的闭包上下文中，比如它引用了某个未被释放的模块实例，那么哪怕页面已经切换，定时器依然在后台运行，死死抓住上下文不放。

遇到这种场景，规范的做法是将定时器 ID 保存到一个独立的变量中，并在退出函数前显式执行 clearInterval。同样适用于异步请求，如果发起的 Ajax 请求返回后不再需要，确保取消请求或忽略后续回调，避免回调函数持有不必要的状态数据。

如何验证是否真的解决了？

知道了原理和修补方法，怎么确认效果呢？光靠肉眼观察是不够的，得交给工具。打开 Chrome 浏览器的 DevTools，切换到 Memory 面板。

1. 先拍一张快照（Take Snapshot），记录基准状态。
2. 执行一遍复现问题的操作步骤。
3. 强制刷新页面或清空缓存，再次执行同样的操作。
4. 对比两张快照中的 heap snapshot，查看 Dominators 树。

重点关注 Detached HTML tree（分离的 HTML 节点）。如果发现有大量的 DOM 节点脱离了文档树却依然存在于内存中，且被闭包引用，那就说明泄漏确实存在。通过对比前后两次快照的差异（Allocation sampling），你能清晰地看到哪个函数分配了过多无法回收的内存。

写在最后

内存管理其实是一种意识，而非单纯的技术细节。在现代前端框架（React、Vue）中，虽然生命周期帮我们屏蔽了很多手动操作，但在封装高阶组件、自定义 Hooks 或引入第三方库时，依然可能引入外部的闭包引用。

日常开发中，养成随手清理的习惯比事后调试更有效。每次写完涉及全局引用、定时器或事件绑定的代码，多问自己一句：“当这个模块不再使用时，它的痕迹能被彻底抹干净吗？” 把这个问题想清楚了，大部分的闭包内存泄漏都能迎刃而解。