JavaScript执行上下文与作用域链详解

本文深入剖析了JavaScript中执行上下文与作用域链这一核心运行时机制，揭示二者如何协同工作：执行上下文作为代码执行的“环境容器”，在全局加载、函数调用或eval执行时动态创建；而作用域链则是在函数定义时静态确立的变量查找路径，沿词法嵌套逐级向上追溯，直至全局——它不仅决定了变量能否被访问，更直接关联着var与let/const的行为差异、闭包的内存驻留原理，以及ReferenceError的本质根源；理解这些，才能真正掌握JS变量生命周期、避免常见陷阱，并写出更健壮、可预测的代码。

JavaScript 的执行上下文（Execution Context）和作用域链（Scope Chain）不是两个独立概念，而是运行时机制的一体两面：执行上下文定义了代码执行的“环境容器”，作用域链则是该容器内查找变量时实际走的那条路径。

执行上下文分哪几种？各自何时创建

JS 引擎每次执行一段可执行代码（global code、function code、eval code）前，都会先创建一个执行上下文。它分为三类：

• Global Execution Context：页面加载时自动创建，对应 window（浏览器）或 globalThis（Node.js），this 指向全局对象
• Function Execution Context：每次调用函数时创建，包含自己的 arguments、this 和词法环境（LexicalEnvironment）
• Eval Execution Context：极少用，且严格模式下禁用，不建议关注

注意：setTimeout 回调、事件处理函数、Promise 回调等异步代码，执行时也各自进入新的函数执行上下文，不是“延续”上一个上下文。

作用域链怎么形成的？为什么找不到变量会报 ReferenceError

作用域链是执行上下文内部的一个只读属性（[[Scopes]]），由当前函数的词法环境向上逐级链接到外层词法环境，最终到全局环境。它在函数定义时就确定（静态），而非调用时决定。

变量查找过程就是沿着这条链逐级搜索：

• 先查当前执行上下文的 LexicalEnvironment（含 let/const 声明）
• 再查 VariableEnvironment（含 var 声明）
• 没找到就跳到外层函数的 LexicalEnvironment，直到全局
• 全程未命中 → 抛出 ReferenceError（不是 undefined）

function outer() {
  const x = 10;
  function inner() {
    console.log(x); // 沿作用域链找到 outer 的 LexicalEnvironment 中的 x
  }
  inner();
}
outer();

var 和 let/const 在作用域链中表现不同？

不是作用域链本身不同，而是它们绑定的位置不同：

• var 声明被提升并绑定到当前执行上下文的 VariableEnvironment，所以能在声明前访问（值为 undefined）
• let/const 绑定到 LexicalEnvironment，但存在“暂时性死区”（TDZ）：从块顶部到声明语句之间，访问会直接抛 ReferenceError
• 两者都遵循同一条作用域链；区别只在于“是否允许在声明前读取”以及“绑定发生的环境对象”

console.log(a); // undefined（var 提升）
console.log(b); // ReferenceError（TDZ）
var a = 1;
let b = 2;

闭包是怎么靠作用域链存活的？

闭包本质是函数对象持有了对其定义时所在词法环境的引用。即使外层函数执行结束、其执行上下文本该被销毁，只要内层函数还存在（比如被返回、被赋值给全局变量），JS 引擎就会保留该外层环境——因为作用域链仍需要它。

容易忽略的关键点：

• 不是所有嵌套函数都是闭包，只有当内部函数在定义它的作用域外部被调用时，才构成闭包
• 闭包捕获的是“变量的绑定”，不是值快照；多个闭包共享同一外层变量（如循环中没用 let 声明 i，所有回调共享同一个 i）
• 滥用闭包可能引发内存泄漏，尤其在 DOM 事件监听或定时器中长期持有大对象

真正难理解的，从来不是“链怎么连”，而是“哪些环境被保留、哪些被释放”——这取决于引擎的垃圾回收策略与你是否无意中维持了对词法环境的强引用。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JavaScript执行上下文与作用域链详解》文章吧，也可关注golang学习网公众号了解相关技术文章。