作用域链是变量查找路径而非生命线，变量生死由其所在作用域生命周期决定：全局变量存至页面关闭，函数/块级变量随作用域退出而销毁，闭包可延长外层变量存活期。
作用域链本身不直接决定变量“生死”，但它决定了变量能否被访问——而能否被访问，又直接影响引擎对变量是否“还活着”的判断。变量的真正生死由其所在作用域的生命周期决定，作用域链只是查找路径；但这条路径一旦断掉（比如外层函数执行完毕、块级作用域退出），内部就再无法触达该变量，引擎随之标记它为“不可达”，进而触发垃圾回收。
作用域链是查找路径，不是生命线
JavaScript 引擎在读取一个变量时，会从当前作用域开始，沿着作用域链逐级向外查找，直到全局作用域。这个过程只解决“能不能找到”，不控制“存不存在”。变量是否存在、何时销毁，取决于它声明时所处的作用域是否还活跃：
- 全局变量：脚本加载即创建，页面关闭才销毁；作用域链始终可达，所以一直“活着”
- 函数内用 let/const/var 声明的变量：函数调用时创建，函数执行结束、上下文弹出后，该作用域失效 → 变量生命周期终止
- 块级作用域（如 if{} 或 for{} 中的 let/const）：块执行开始时创建，块执行结束立即销毁；即使函数还没返回，块级变量也已消亡
变量“死”的两个关键信号
引擎判定一个变量可以被回收，通常基于以下任一条件成立：
- 它所属的作用域对象（Execution Context 的 LexicalEnvironment）已从调用栈中移除，且无其他引用指向它
- 它所在的词法环境（如 Block Environment）已退出，且没有闭包捕获它
例如：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
function outer() {
let x = "alive inside outer";
if (true) {
let y = "alive only in this block";
console.log(y); // ✅ 可访问
}
console.log(y); // ❌ ReferenceError：块已退出，y 所在环境销毁，作用域链里再也找不到 y
return () => x; // ✅ 闭包保留对 x 的引用，outer 执行完 x 也不会立即销毁
}
闭包让变量“续命”，靠的还是作用域链
当内层函数引用了外层作用域的变量，并被返回或传递出去，JavaScript 会保留那个外层词法环境——不是因为作用域链变长了，而是因为引擎发现：这条链上某个环节仍被活跃引用。此时变量虽脱离原函数执行期，却因闭包持续“存活”。
- 没有闭包：函数执行完，它的词法环境被销毁，变量立即不可访问 → 进入垃圾回收候选
- 有闭包：引擎保留外层词法环境，变量继续存在于内存中，作用域链依然能查到它
var 和 let/const 在“生死节奏”上的差异
它们都受作用域生命周期约束，但“何时开始存在”不同，间接影响你感知的“生死时间点”：
- var：函数作用域，有变量提升，进入函数时就分配内存（哪怕声明在后面），函数结束才销毁
- let/const：块级作用域，无提升，存在暂时性死区（TDZ）；变量在声明语句执行时才真正“出生”，块结束即“死亡”
也就是说，let x 不是“不存在”，而是“还没到出生时刻”——作用域链能找到它所在环境，但引擎拒绝访问，直到声明执行完毕。
