JavaScript中什么是作用域链_变量查找规则你清楚吗

作用域链是函数定义时确定的静态嵌套引用链，基于[[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 引擎无法在编译期静态确定变量归属，从而禁用大部分优化（如变量内联、作用域链缓存），并强制进入慢路径查找。现代代码应避免使用。

例如：

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 标签里找。