闭包内存泄漏的根源在于捕获整个词法环境而非单个变量，导致未使用的大型对象无法回收；应通过解构、传参、事件委托等方式最小化捕获范围。
闭包本身不占多少内存，真正让内存涨上去的，是它捕获的变量和这些变量背后的引用链。只要闭包还活着，它能访问到的外部变量就无法被垃圾回收——哪怕只用了一个字段，整个词法环境（包括没用到的大数组、DOM 节点、缓存对象）都得一起留在堆里。
闭包捕获的是词法环境，不是单个变量
JavaScript 引擎在创建闭包时，会为它关联一个完整的词法环境对象（Lexical Environment），这个对象在堆中分配内存。即使闭包内部只读取 config.url，也可能连带锁住 config.data 这个百万项数组——因为它们同属一个作用域，引擎无法自动剔除“未使用”的部分。
- 闭包不“选择性捕获”，而是绑定整个外层作用域的变量对象
- V8 等现代引擎虽会对 let 声明做优化，但前提是变量确实未被访问；若代码中有潜在引用（如 console.log(obj)），仍可能保留整块数据
- 多个闭包来自同一外层函数时，哪怕只有一个用了大对象，其余闭包也会让它无法释放（共享词法环境“连坐”）
高频生成 + 长期持有 = 内存快速堆积
for 循环里每次迭代新建闭包，1000 次就是 1000 个独立作用域副本。每个副本都持有一份变量引用，而一旦这些闭包被挂到 DOM、全局对象或定时器上，它们就变成“长期居民”，拖着各自的数据不放。
- 实测显示：每创建 1 万个简单闭包（如计数器），内存增长可达 8.7MB；等效无闭包实现仅需 3.2MB
- var 声明的循环变量会让所有闭包共享同一变量，不仅逻辑出错，还导致冗余引用长期滞留
- 事件监听器未解绑、定时器未清除、闭包赋值给单例或路由守卫，等于给变量上了“永久枷锁”
大型对象一旦被捕获，就很难释放
闭包若直接持有 DOM 元素、大数组、未序列化的状态对象或 WebSocket 实例，这些资源就会长期驻留堆内存。尤其当节点已从页面移除，但闭包仍强引用着它，整棵子树都无法被回收。
- 典型高危对象：缓存 Map、base64 图片字符串、Canvas 上下文、数据库连接
- 闭包内写 el.onclick = () => console.log(el)，等于把整个 DOM 节点及其子树锁死
- 异步回调中访问组件实例（如 Vue 的 this 或 React 的 props），组件卸载后仍被引用，造成内存泄漏
如何让闭包只拿它真正需要的东西
目标不是消灭闭包，而是让它的“行李”尽可能轻：只携带执行必需的最小信息，其余交由外部统一管理。
- 用解构提前提取必要字段：const { id, name } = item，再让闭包只捕获这两个轻量值
- 避免闭包整个对象，改用传参方式传递计算结果：onClick={() => handleClick(item.id)}
- 定时器优先用 setTimeout(cb, delay, arg1, arg2) 第三参数传参，绕过作用域捕获
- 列表渲染改用事件委托 + data-id 查找，彻底规避为每个节点创建独立闭包
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
