作用域链是函数定义时确定的静态嵌套引用链，基于[[Scope]]逐层向上查找变量，只取决于定义位置而非调用位置；未声明变量读取返回undefined，严格模式下写入才抛ReferenceError。
作用域链的本质是词法作用域的嵌套引用链
JavaScript 的作用域链不是运行时动态构建的“搜索路径”，而是函数定义时就确定的、由 [[Scope]]（或现代引擎中的闭包环境记录）维护的一组静态嵌套关系。每次函数执行，引擎会基于这个链逐层向上查找变量，直到全局作用域。
关键点在于：查找只看「函数在哪定义」，不看「函数在哪调用」。比如一个内层函数被返回并赋值给全局变量后调用，它依然沿原定义位置的作用域链查找，而非调用位置的作用域。
变量查找失败时不会报错，而是返回 undefined
只有在严格模式下对未声明变量进行赋值（如 foo = 42）才会抛出 ReferenceError；而单纯读取未声明变量（如 console.log(missing)）始终返回 undefined，哪怕查到全局作用域也没找到。
- 常见误判：以为
ReferenceError表示“变量不存在”，其实它只发生在「写入未声明变量」或「访问let/const声明前的暂时性死区」 -
var声明会被提升，但初始化不会；let/const声明和初始化都被绑定到暂时性死区 - 全局对象上的属性（如
window.x）和真正用var声明的全局变量行为不完全等价——后者不可删除，前者可删
with 和 eval 会动态污染作用域链
这两个语句会让 JavaScript 引擎无法在编译期静态确定变量归属，从而禁用大部分优化（如变量内联、作用域链缓存），并强制进入慢路径查找。现代代码应避免使用。
立即学习“Java免费学习笔记（深入）”；
例如：
function f() {
const obj = { x: 1 };
with (obj) {
console.log(x); // 运行时才知道 x 来自 obj，作用域链临时插入 obj 环境
}
}
-
with在严格模式下直接语法错误 -
eval如果含变量声明，会在当前作用域注入新绑定，破坏静态分析 - 打包工具（如 Webpack）遇到
eval通常会关闭作用域提升优化
闭包让外层作用域“活下来”，但不等于“捕获全部变量”
闭包保留的是对外层词法环境的引用，但只保留实际被内部函数引用的那些变量（V8 称为“context slot”）。没被引用的变量仍可能被 GC 回收。
比如：
function makeCounter() {
let count = 0;
const unused = new Array(1000000); // 很大但没被返回的函数使用
return () => ++count;
}
const inc = makeCounter(); // unused 不会常驻内存
- 不要默认认为“用了闭包=内存泄漏”，现代引擎做了精细的上下文剪枝
- 调试时看到 DevTools 中显示整个外层作用域，只是快照视图，不代表所有变量都真实保留在内存中
- 用
console.dir(fn)查看[[Scopes]]可以确认哪些变量被真正闭包持有
window 或 globalThis，而是当前执行上下文的 LexicalEnvironment 链末端——它可能是模块顶级作用域、函数作用域，也可能是 eval 创建的特殊环境。查不到变量时，引擎不会跳去其他模块或 script 标签里找。 
