闭包导致内存泄漏的核心是其使本该被垃圾回收的词法环境因持续引用而无法释放：函数执行完毕后，若内部函数被外部变量引用，其[[Scopes]]属性会牢牢绑定父作用域，导致局部变量（如大数组、DOM节点）长期驻留内存。
闭包引起的“内存泄漏”，核心不是闭包本身有错，而是它让本该被回收的词法环境（即外部函数的作用域）长期驻留在内存中——因为仍有活跃引用指向它。
词法环境为何本该被销毁？
函数执行完毕后，其执行上下文出栈，对应的词法环境（含局部变量、内部函数等）若无任何引用，就会被垃圾回收器（GC）自动清理。这是JS内存管理的正常流程。
但闭包打破了这个节奏：当内部函数被返回并赋值给外部变量（如全局变量、对象属性、事件回调等），这个函数对象的 [[Scopes]] 属性仍牢牢指向父函数的词法环境。只要该闭包函数还“活着”，父函数的词法环境就无法被释放。
典型泄漏场景：引用未断，环境不退
-
未手动解除闭包引用：例如
const fn = outer();调用后，后续不再使用fn，却未执行fn = null;，导致整个outer的词法环境持续占用内存。 -
闭包绑定大对象或DOM节点：如闭包内引用了
new Array(1000000)或document.getElementById('app')，即使DOM已移除、数组已无业务用途，只要闭包存在，这些资源就无法回收。 - 多个闭包共享同一词法环境：一个作用域里定义了多个函数，其中仅一个函数实际用到了某个大变量，但其他函数也因共享作用域而间接“拖住”该变量，造成无效驻留。
关键判断标准：是否“可触达”
JS内存泄漏的本质是：内存已不再需要，但因存在可触达的引用链，GC无法标记并回收。闭包制造的正是这样一条隐性引用链——从全局变量 → 闭包函数 → [[Scopes]] → 父词法环境 → 局部变量/对象。
这不是语法错误，而是逻辑疏忽：开发者以为“函数调用结束=资源释放”，却忽略了闭包带来的持久化绑定关系。
如何避免？主动切断引用是关键
- 闭包使用完毕后，显式置为
null或重新赋值，解除对外部函数词法环境的持有。 - 避免在闭包中引用不必要的大型数据结构；必要时，只传递所需字段而非整个对象。
- 在组件卸载、模块销毁等生命周期节点，统一清理闭包变量（尤其配合定时器、事件监听器时）。
