闭包不破坏标记清除算法，但通过词法环境引用链使外层变量持续可达，导致本该回收的对象无法释放；不合理使用（如长期持有DOM节点或大数组）易引发内存泄漏，需控制引用粒度、及时解绑并主动断开不必要的强引用。
闭包本身不会破坏垃圾回收器的标记清除算法，但会改变变量的可达性，从而影响哪些对象被判定为“可回收”。
闭包让本该被回收的变量持续存活
在标记清除过程中，GC从根对象（如全局对象、当前执行上下文中的变量）出发，标记所有能通过引用链访问到的对象。闭包会形成一个“词法环境引用链”，使外层函数作用域中的变量对内层函数保持可达——哪怕外层函数已执行完毕、执行上下文被销毁。
例如：
function createCounter() {
let count = 0; // 这个变量本应在createCounter返回后被回收
return function() {
count++; // 但因为被内部函数引用，它持续“活”在闭包中
return count;
};
}
const counter = createCounter(); // 此时count仍被保留，无法被GC回收
只要 counter 还在作用域中（比如是全局变量或被其他活跃对象引用），它所捕获的 count 就始终处于“可达”状态，GC不会将其清除。
立即学习“Java免费学习笔记（深入）”；
不合理的闭包容易引发内存泄漏
当闭包意外持有了大对象（如 DOM 节点、大型数组、缓存数据），且该闭包长期存在（如绑定在全局事件监听器、定时器或缓存对象上），就会导致这些大对象无法释放。
- 常见场景：为 DOM 元素绑定事件时，闭包中引用了该元素或其父级容器，又未及时解绑；
- 典型陷阱：用闭包缓存计算结果，但缓存对象本身未做大小限制或过期清理；
- 隐蔽问题：循环引用 + 闭包（尤其在旧版 IE 中更严重），现代引擎虽能处理，但逻辑复杂时仍可能延长对象生命周期。
优化建议：控制闭包的引用粒度与生命周期
闭包不是洪水猛兽，关键在于明确“谁在引用谁”以及“引用何时结束”：
- 只捕获真正需要的变量，避免在闭包中无意引用整个外部作用域（可用立即执行函数或显式参数传入来缩小捕获范围）；
- 及时解除强引用：事件监听器用完就 removeEventListener，定时器记得 clearTimeout，缓存对象设最大容量并淘汰旧项；
- 必要时主动断开引用：将闭包中不再需要的大对象设为 null，协助 GC 判断其不可达；
- 借助开发者工具（如 Chrome DevTools 的 Memory 面板）录制堆快照，对比操作前后的对象保留路径，确认闭包是否意外延长了对象寿命。
标记清除算法依然正常工作，只是闭包扩展了“根可达”的边界。理解这一点，就能把闭包用得既安全又高效。
