闭包中未使用的巨大局部变量不会被GC自动清理，关键在于是否仍被词法环境间接持有；只要闭包函数可达，其捕获的全部变量（包括未访问的大对象）均保持可达，必须显式断开引用才能释放。
JavaScript 的垃圾回收器（GC）本身不“识别闭包”或“分析变量用途”，它只基于可达性（reachability）判断对象是否可回收。闭包中未使用的巨大局部变量能否被清理，关键在于：该变量是否还被闭包函数的词法环境（LexicalEnvironment）所间接持有——哪怕你主观认为“没用了”，只要引用链未断，GC 就不会释放。
闭包变量是否存活，取决于“是否还能被访问”
JS 引擎（如 V8）使用标记-清除（Mark-and-Sweep）机制。从根对象（全局对象、当前执行上下文中的活动变量、寄存器等）出发，沿引用链递归标记所有可达值；未被标记的对象在后续阶段被清除。
闭包的本质是函数与其创建时所在词法环境的绑定。只要闭包函数对象本身仍可达（比如被赋值给全局变量、作为事件监听器、被其他闭包引用等），它内部捕获的整个词法环境（包括那些“看似没用”的大变量）就都保持可达。
例如：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
function createHandler() {
const hugeData = new Array(1000000).fill('x'); // 占内存
const config = { timeout: 5000 };
return function() {
console.log(config.timeout); // 只用到了 config
// hugeData 完全没被访问，但依然被闭包捕获
};
}
const handler = createHandler(); // hugeData 此时无法被 GC
主动切断无用引用是唯一可靠方式
引擎不会做“死变量分析”（如编译器级别的 DCE）。你必须显式解除对不需要的大对象的引用，才能让 GC 在下次回收周期中释放它。
- 在闭包函数体内部，手动将局部大变量设为 null 或 undefined（仅当确定后续绝不再访问）
- 把真正需要的数据抽离出来，避免捕获整个作用域
- 用立即执行函数（IIFE）或块级作用域（
{}+let）提前限制变量生命周期
优化示例：
function createHandler() {
const hugeData = new Array(1000000).fill('x');
const config = { timeout: 5000 };
// 提前释放 hugeData，只保留 config
const keep = { ...config };
hugeData = null; // 显式切断引用
return function() {
console.log(keep.timeout);
};
}
V8 中的优化：Context 剪枝（Context Disposal）
V8 在某些条件下会进行上下文剪枝（context disposal）：如果静态分析发现某个捕获的变量在闭包函数中从未被读取或写入，且该函数没有通过 eval、with 或访问 arguments 等动态特性，V8 可能不会将其纳入闭包的词法环境。
但这属于引擎实现细节，不可依赖。不同版本 V8 表现可能不同，且一旦加入任何动态访问（如 console.log(this)、typeof hugeData），剪枝就会失效。
验证是否释放：用 Chrome DevTools Memory 快照
实际排查时，可通过以下步骤确认大对象是否残留：
- 打开 DevTools → Memory 面板
- 点击 “Take heap snapshot”（生成快照）
- 触发闭包创建和使用后，再拍一次快照
- 切换到 “Comparison” 视图，筛选
Array或Object，查看新增/未释放实例 - 右键某实例 → “Retainers” 查看谁在持有它（常会看到 Closure → Context → Variable
