JavaScript垃圾回收依赖执行上下文生命周期：函数执行结束时上下文被标记销毁，局部变量若无其他引用则被回收；闭包会延迟外部变量销毁，可能引发内存泄漏；全局变量因全局上下文永不销毁而需手动解除引用。
JavaScript 的垃圾回收（GC）机制与执行上下文的生命周期紧密相关。理解执行上下文如何被创建、使用和销毁，是掌握 GC 工作原理的关键切入点——因为变量是否可被回收，本质上取决于它是否还存在于某个活跃的执行上下文中。
执行上下文销毁是垃圾回收的触发前提
每当函数执行结束，其对应的执行上下文（Execution Context）就会从调用栈中弹出并被标记为“待销毁”。此时，引擎会检查该上下文中声明的变量对象（VO）或词法环境（Lexical Environment）中的绑定（bindings），判断其中的值是否还有其他引用路径。如果没有，这些值所指向的对象就成为垃圾回收的目标。
注意：销毁执行上下文 ≠ 立即回收内存。它只是移除了一个强引用来源，是否真正回收取决于垃圾回收器后续的可达性分析（如标记-清除算法）。
局部变量通常在上下文销毁后变得不可达
函数内用 let、const 或 var 声明的局部变量，其绑定存在于该函数的词法环境中。一旦函数返回，执行上下文销毁，这些绑定消失，变量标识符不再可访问。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 若变量值是基本类型（如数字、字符串），值本身直接存储在上下文中，销毁即释放
- 若变量值是对象（如数组、对象字面量、闭包函数），销毁上下文仅断开对它的引用；只有当该对象没有其他引用（比如未被外部闭包捕获、未被全局变量保存、未被事件监听器持有）时，才会被回收
闭包让执行上下文的部分内容“延迟销毁”
当内部函数引用了外部函数的变量，JS 引擎会保留外部函数的词法环境（至少是其中被引用的部分），即使外部函数已执行完毕、执行上下文本应销毁。这导致：
- 外部函数的执行上下文不能被完全清理，相关变量持续存活
- 如果闭包长期存在（如被赋给全局变量、作为回调保存在定时器或事件监听器中），它所捕获的变量也无法被回收，可能引发内存泄漏
- 现代引擎（如 V8）会做“闭包优化”，只保留实际被引用的变量，而非整个外层词法环境
全局执行上下文几乎永不销毁，全局变量难回收
全局执行上下文在页面生命周期内一直存在（直到标签页关闭）。因此，在全局作用域中声明的变量（如 var a = {} 或 window.b = []）始终有强引用，不会因“上下文销毁”而进入回收流程。
要让全局对象可回收，必须显式切断引用：
- a = null（解除变量绑定）
- delete window.b（仅对非声明式属性有效）
- 避免意外挂载到 window 或 globalThis
