浏览器回收闭包内存取决于其执行上下文是否被外部引用：若无外部引用，垃圾回收器通过标记-清除机制将其清理；闭包本身非特殊类型，GC只判断引用可达性，而非语法形式。
浏览器回收闭包占用的内存，核心取决于“闭包是否还被外部引用”。只要闭包所依赖的私有上下文（即函数执行时创建的执行上下文）仍被外部持有，它就不会被回收；一旦所有外部引用消失，垃圾回收器就会在下一次运行时将其清理掉。
闭包不等于自动驻留内存
很多人误以为“用了闭包，变量就永远存在”。其实不然。闭包只是让上下文**有可能**不被释放——前提是：该上下文中某个值（通常是函数对象或其内部变量的引用）被外部变量、事件监听器、定时器、全局对象等持续持有。
例如：
- 被返回的函数引用着私有变量 → 上下文保留 → 形成有效闭包 → 暂时不回收
- 返回的函数被赋值给变量后又被设为 null → 引用断开 → 下次 GC 可回收
- 闭包内变量只被内部使用，无任何外部引用 → 函数执行完，上下文正常出栈释放
GC 如何判断闭包能否回收？
现代浏览器（如 Chrome 的 V8）主要采用标记-清除（Mark-and-Sweep）机制：
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 从根对象（global/window、调用栈中的活跃变量、DOM 元素等）出发，递归标记所有可达对象
- 闭包对应的执行上下文（EC）及其 AO（活动对象）若无法从根到达，就被标记为“不可达”
- 随后在清除阶段，整个上下文连同其中的私有变量一并释放
注意：闭包本身不是特殊数据类型，GC 不识别“这是闭包”，它只看“这个执行上下文是否还有活引用”。所以关键不在写法，而在引用链是否断裂。
哪些情况会让闭包难以被回收？
以下做法容易导致闭包长期驻留，引发内存泄漏：
- 把闭包函数赋给全局变量或未清理的事件监听器（
element.addEventListener('click', handler)但没removeEventListener） - 用闭包缓存大量数据（如大数组、DOM 节点），又没提供清除逻辑
- 定时器中持有闭包（
setInterval(fn, 1000)），而fn又捕获了大对象 - 循环引用 + 闭包（比如对象 A 存闭包，闭包里又存 A）——V8 虽能处理多数循环引用，但复杂嵌套仍可能延缓回收
怎么主动协助 GC 回收闭包？
不需要手动调 GC，但可以切断引用链，让闭包变“不可达”：
- 将引用闭包的变量设为
null或undefined - 移除 DOM 事件监听器（尤其用闭包绑定的）
- 清除定时器（
clearInterval/clearTimeout） - 避免在闭包中长期持有大型对象（如整个
document或高分辨率图片的 base64）
比如：let timer = setInterval(() => { /* 闭包逻辑 */ }, 100); ... clearInterval(timer); timer = null; —— 这样 GC 就能安全回收相关上下文。
