闭包本身不占大量内存，但会延长变量可达性路径，导致本该释放的变量被锁住；高频创建闭包（如proxy拦截器中动态返回）引发堆内存快速堆积；闭包持有dom、xhr等不可回收资源时，会连带保留整棵引用树；清理滞后（如未移除事件监听器、未清除定时器）使引用链长期有效，放大内存泄漏风险。
闭包本身不分配大量内存，但它会让本该及时释放的变量“卡”在内存里，导致垃圾回收器（GC）反复扫描、频繁工作却收效甚微。
闭包延长了变量的可达性路径
JavaScript 的 GC 依赖“可达性分析”：只要一个对象还能被全局、活跃定时器、事件监听器或闭包等根对象访问到，它就不会被回收。闭包在创建时会绑定整个词法环境，哪怕只用了一个字段，也可能把同作用域里的大数组、DOM 节点、响应数据等一并锁住。这些变量本应在函数执行完就释放，却因闭包存在而持续“可达”。
高频触发场景会制造短生命周期对象洪流
比如 Proxy 的 get 或 set 拦截器里每次调用都动态返回新闭包：
-
handler.get = () => () => obj[key];
这种写法会让每次属性访问都新建函数对象，快速堆积堆内存。V8 的 young gen 频繁触发 scavenge，但每次只回收少量对象，new space 使用率却迅速回升——这是典型的分配压力信号。
闭包常与不可回收资源强绑定
当闭包持有 DOM 元素、XMLHttpRequest 实例或 ArrayBuffer 时，问题更严重：
- 一个按钮节点被闭包引用，它的
parentNode、childNodes、绑定的事件处理器都会被连带保留； - 若该按钮曾渲染过百个子元素，整棵 detached DOM 树就无法释放，即使页面早已移除它。
清理滞后让引用链长期有效
常见情况包括：
- 组件卸载后未调用
removeEventListener，闭包仍挂在已销毁的 DOM 上 -
setInterval回调是闭包，忘记clearInterval，定时器持续运行并维持对this、状态对象的引用 - 把闭包赋给
window.xxx或模块顶层变量，使其生命周期与页面等长
本质上，不是闭包太重，而是它成了引用管理的“放大器”——把本可瞬时释放的对象，拖进中长期驻留队列，迫使 GC 不得不更频繁、更费力地介入。
