JavaScript 执行上下文与调用栈：从原理到调试实战

1. 引言

JavaScript 是一门单线程语言，这意味着同一时刻只能执行一个任务。那么，JavaScript 引擎是如何管理代码的执行顺序、变量的作用域以及函数之间的调用关系的呢？答案就是执行上下文（Execution Context） 与调用栈（Call Stack）。

理解这两个核心概念，不仅能帮你理清代码的执行流程，还能让你从容应对「栈溢出（Stack Overflow）」这类经典错误，并掌握高效的调试方法。本文将从执行上下文的组成讲起，逐步深入到调用栈与调试实战。

在开始之前，我们先明确一个关键认知：JavaScript 的代码执行并不是「从上到下、逐行运行」这么简单 。引擎在执行任何代码之前，都需要先进行一系列的准备和编译工作，而执行上下文正是这一过程中的核心产物。它决定了变量在哪里、函数如何被调用、this 指向谁，以及作用域链如何构建。

本文适合以下读者：

• 已经掌握 JavaScript 基础语法，但想深入理解运行机制的开发者。
• 面试前需要系统梳理「执行上下文」「作用域」「闭包」等核心概念的求职者。
• 遇到「栈溢出」「变量提升」等报错，想从原理层面解决问题的工程师。

读完本文，你将能够：

1. 清晰描述执行上下文的组成与创建过程。
2. 区分变量环境与词法环境，理解 var 与 let/const 的本质差异。
3. 用调用栈模型解释函数调用的执行顺序。
4. 定位并解决栈溢出问题。
5. 熟练使用多种调试手段追踪调用栈。

2. 执行上下文（Execution Context）

2.1 什么是执行上下文

执行上下文是 JavaScript 代码被解析和执行时的环境抽象。每当 JavaScript 引擎要执行一段代码时，都会先创建一个对应的执行上下文，用于保存该段代码运行所需的全部信息。

可以把它理解为一个「运行时的容器」：这个容器里装着当前代码能访问到的所有变量、函数、this 指向，以及对外层作用域的引用。当代码执行时，引擎会在这个容器中查找变量、执行函数调用。

JavaScript 中存在三种执行上下文：

• 全局执行上下文 ：程序启动时创建，是默认的、最外层的上下文，对应 window（浏览器）或 global（Node.js）。整个程序只有一个全局上下文，它会在程序生命周期内一直存在。
• 函数执行上下文：每次调用一个函数时，都会为该函数创建一个新的执行上下文。函数执行完毕后，该上下文会被销毁（除非有闭包引用）。
• Eval 执行上下文 ：执行 eval() 函数内部的代码时创建（不推荐使用，此处仅作了解）。

为了更直观地理解，我们看一个例子：

var globalVar = "我是全局变量";

function outer() {
  var outerVar = "我是 outer 的变量";
  
  function inner() {
    var innerVar = "我是 inner 的变量";
    console.log(globalVar); // 可以访问全局变量
    console.log(outerVar);  // 可以访问 outer 的变量
    console.log(innerVar);  // 可以访问自己的变量
  }
  
  inner();
}

outer();

当这段代码运行时，引擎会依次创建：

1. 全局执行上下文 ：包含 globalVar 和 outer 函数。
2. outer 函数执行上下文 ：包含 outerVar 和 inner 函数。
3. inner 函数执行上下文 ：包含 innerVar。

每个上下文都通过作用域链 连接起来，inner 可以向上查找 outer 和全局作用域中的变量，这就是闭包能够工作的基础。

下面是三种执行上下文的关系示意图：

flowchart TD A["全局执行上下文"] --> B["outer() 函数执行上下文"] B --> C["inner() 函数执行上下文"] A --> D["Eval 执行上下文"] C --> E["作用域链：inner → outer → 全局"] B --> E

2.2 执行上下文的创建阶段

当一个执行上下文被创建时，引擎会经历两个阶段：创建阶段 和 执行阶段。

创建阶段（Creation Phase）

在创建阶段，引擎会完成三件事：

1. 创建变量环境（Variable Environment）。
2. 创建词法环境（Lexical Environment）。
3. 确定 this 的指向。

这个阶段发生在代码真正执行之前，引擎会「扫描」当前作用域内的所有声明，并提前在环境中登记它们。这就是变量提升（Hoisting）的根源------声明在创建阶段就已经被处理了。

执行阶段（Execution Phase）

在执行阶段，引擎会逐行执行代码，完成变量的赋值、函数的调用等操作。此时，如果访问一个在创建阶段未登记的变量，就会抛出 ReferenceError。

我们通过一个例子来观察这两个阶段：

console.log(a); // 创建阶段已登记 a，值为 undefined
var a = 10;
console.log(a); // 执行阶段已赋值，输出 10

创建阶段 ：引擎扫描到 var a，在变量环境中登记 a，初始值为 undefined。

执行阶段 ：第一行 console.log(a) 输出 undefined；第二行执行赋值 a = 10；第三行输出 10。

this 的确定

this 的指向在创建阶段就被确定，它遵循以下规则：

• 全局上下文 ：this 指向全局对象（浏览器中为 window，Node.js 中为 global）。
• 函数上下文 ：this 取决于函数的调用方式：
  • 普通函数调用：this 指向全局对象（严格模式下为 undefined）。
  • 对象方法调用：this 指向该对象。
  • call/apply/bind：this 指向传入的第一个参数。
  • 箭头函数：this 继承自外层作用域。

const obj = {
  name: "obj",
  normalFunc: function () {
    console.log(this.name); // "obj"，this 指向 obj
  },
  arrowFunc: () => {
    console.log(this.name); // 全局作用域下 this 指向 window，window.name 为 undefined
  },
};

obj.normalFunc();
obj.arrowFunc();

下面我们重点讲解变量环境与词法环境。

下面是执行上下文创建与执行两个阶段的流程图：

flowchart LR A["代码开始执行"] --> B["创建阶段"] B --> B1["创建变量环境"] B --> B2["创建词法环境"] B --> B3["确定 this 指向"] B1 --> C["执行阶段"] B2 --> C B3 --> C C --> D["逐行执行代码"] D --> E["完成赋值与函数调用"]

3. 变量环境与词法环境

3.1 变量环境（Variable Environment）

变量环境用于存放由 var 声明的变量以及函数声明。在创建阶段，引擎会执行「变量提升（Hoisting）」：

• var 声明的变量会被提升到作用域顶部，并初始化为 undefined。
• 函数声明会被整体提升，因此可以在声明之前调用。

console.log(a); // undefined（已提升，但未赋值）
var a = 10;

sayHello(); // "Hello"（函数声明整体提升）
function sayHello() {
  console.log("Hello");
}

变量提升的细节

变量提升的本质是：声明被提升，赋值留在原地 。也就是说，var a = 10 会被拆成两部分：

• 声明部分 var a 被提升到作用域顶部。
• 赋值部分 a = 10 留在原来的位置。

// 实际执行顺序（引擎视角）
var a;           // 声明被提升
console.log(a);  // undefined
a = 10;          // 赋值留在原地

函数声明 vs 函数表达式

函数声明会整体提升，但函数表达式不会：

// 函数声明：可以提前调用
foo(); // "foo 被调用"
function foo() {
  console.log("foo 被调用");
}

// 函数表达式：提前调用会报错
bar(); // TypeError: bar is not a function
var bar = function () {
  console.log("bar 被调用");
};

这是因为 var bar 被提升为 undefined，而 undefined 不是函数，所以调用时抛出 TypeError。

变量环境的内部结构

变量环境内部包含一个环境记录（Environment Record），它维护了一张「标识符 → 值」的映射表。当代码中访问一个变量时，引擎会先在当前环境记录中查找，找不到再沿着作用域链向上查找。

var x = 1;
var y = 2;

function demo() {
  var x = 10; // 遮蔽（shadowing）全局的 x
  console.log(x); // 10，优先使用局部变量
  console.log(y); // 2，局部没有 y，向上查找全局
}

demo();

在这个例子中，demo 函数内部的 x 遮蔽了全局的 x，而 y 则通过作用域链在全局环境中找到。

3.2 词法环境（Lexical Environment）

词法环境用于存放 let、const 声明的变量，以及闭包所需的对外层作用域的引用。与 var 不同：

• let 和 const 也会被提升，但会进入「暂时性死区（Temporal Dead Zone, TDZ）」，在声明之前访问会抛出 ReferenceError。

console.log(b); // ReferenceError: Cannot access 'b' before initialization
let b = 20;

暂时性死区（TDZ）

暂时性死区是指：从作用域开始到变量声明完成之间的区域。在这个区域内访问该变量，会抛出 ReferenceError。

{
  // TDZ 开始
  console.log(c); // ReferenceError
  let c = 30;
  // TDZ 结束，c 已初始化
  console.log(c); // 30
}

TDZ 的存在是为了提醒开发者：在使用变量之前，必须先完成声明 。这比 var 的「静默 undefined」更安全，能帮助我们在开发阶段就发现潜在问题。

块级作用域

let 和 const 引入了真正的块级作用域 ，{}、if、for、while 等都会创建新的作用域：

if (true) {
  let blockVar = "只在块内可见";
  var functionVar = "函数级作用域";
}
console.log(blockVar); // ReferenceError: blockVar is not defined
console.log(functionVar); // "函数级作用域"，var 不受块级限制

词法环境与闭包

词法环境的一个重要特性是：它保存了对外层作用域的引用。当内部函数被返回并在外部调用时，它仍然可以通过这个引用访问外层作用域的变量，这就是闭包（Closure）。

function createCounter() {
  let count = 0; // 这个变量被闭包捕获
  
  return function () {
    count++;
    return count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

即使 createCounter 已经执行完毕，返回的函数仍然可以通过词法环境引用 count，因此计数器可以持续累加。

let 与 const 的区别

• let：允许重新赋值。
• const：声明时必须初始化，且不能重新赋值（但对象/数组内部可以修改）。

let num = 1;
num = 2; // 合法

const fixed = 10;
fixed = 20; // TypeError: Assignment to constant variable

const obj = { name: "obj" };
obj.name = "new name"; // 合法，const 只限制绑定，不限制内容

3.3 两者的关系

简单来说，变量环境 是 ES5 时代「作用域」的实现方式，而 词法环境 是 ES6 引入 let/const 后，为了支持块级作用域而新增的机制。两者共同构成了执行上下文中的「环境记录（Environment Record）」。

特性	变量环境	词法环境
存放内容	var 声明、函数声明	let、const 声明
提升行为	提升并初始化为 undefined	提升但进入暂时性死区
作用域	函数级作用域	块级作用域
典型场景	全局变量、函数内部 var	let/const、块级 {}

下面是变量环境与词法环境的对比关系图：

flowchart TD A["执行上下文"] --> B["变量环境"] A --> C["词法环境"] B --> B1["存放 var 声明"] B --> B2["存放函数声明"] B --> B3["变量提升 → undefined"] C --> C1["存放 let / const 声明"] C --> C2["暂时性死区 TDZ"] C --> C3["保存外层作用域引用"] C3 --> D["闭包（Closure）"]

4. 调用栈（Call Stack）

4.1 什么是调用栈

调用栈是 JavaScript 引擎用来追踪函数调用关系的一种数据结构（后进先出，LIFO）。每当调用一个函数，引擎就会把该函数的执行上下文压入栈顶；函数执行完毕，则从栈顶弹出。

function first() {
  console.log("first");
  second();
}

function second() {
  console.log("second");
}

first();

执行过程如下：

1. 全局上下文入栈。
2. 调用 first()，first 上下文入栈。
3. first 内调用 second()，second 上下文入栈。
4. second 执行完毕，出栈。
5. first 执行完毕，出栈。
6. 全局上下文最终出栈，程序结束。

4.2 调用栈的图示

flowchart TD A["全局执行上下文"] --> B["first() 执行上下文"] B --> C["second() 执行上下文"] C --> D["second 执行完毕，出栈"] D --> E["first 执行完毕，出栈"] E --> F["全局上下文出栈，程序结束"]

5. 栈溢出（Stack Overflow）

5.1 什么是栈溢出

当调用栈中的上下文数量超过引擎设定的最大栈深度 时，就会抛出 RangeError: Maximum call stack size exceeded，这就是栈溢出。

栈溢出的本质

栈溢出本质上是内存资源耗尽的一种表现。调用栈在内存中占据一块固定大小的区域（通常为 1MB 左右），每当一个函数被调用，引擎就会在栈上分配一块空间来存放该函数的执行上下文。当函数调用层级过深，栈空间被占满时，引擎就无法再为新的调用分配空间，从而抛出栈溢出错误。

最常见的触发原因：无限递归

function recurse() {
  recurse(); // 无限调用自身
}

recurse(); // RangeError: Maximum call stack size exceeded

其他触发场景

除了无限递归，以下场景也可能导致栈溢出：

• 过深的递归：即使递归有终止条件，但如果递归深度过大（如处理超大数据集），同样可能耗尽栈空间。
• 相互调用：两个函数互相调用，形成循环调用链。

// 相互调用导致的栈溢出
function ping() {
  pong();
}

function pong() {
  ping();
}

ping(); // RangeError: Maximum call stack size exceeded

• 过深的 DOM 遍历：在处理深层嵌套的 DOM 结构时，如果使用递归遍历，也可能触发栈溢出。

// 递归遍历深层 DOM 可能栈溢出
function walk(node) {
  // 处理当前节点...
  for (const child of node.children) {
    walk(child); // 层级过深时可能溢出
  }
}

栈溢出的报错信息解读

当栈溢出发生时，控制台会输出类似以下信息：

RangeError: Maximum call stack size exceeded
    at recurse (repl:2:3)
    at recurse (repl:2:3)
    at recurse (repl:2:3)
    ...

注意堆栈信息中大量重复的相同调用，这正是无限递归的典型特征，能帮你快速定位问题所在。

5.2 如何避免栈溢出

确保递归有明确的终止条件

递归函数必须有一个基线条件（base case），当满足该条件时停止递归：

// 正确的递归：有明确的终止条件
function factorial(n) {
  if (n <= 1) return 1; // 基线条件
  return n * factorial(n - 1);
}

console.log(factorial(5)); // 120

将递归改写为迭代

对于深度较大的递归，改用循环可以完全避免栈溢出：

// 递归：计算阶乘
function factorial(n) {
  if (n <= 1) return 1;
  return n * factorial(n - 1);
}

// 迭代：避免栈溢出
function factorialIterative(n) {
  let result = 1;
  for (let i = 2; i <= n; i++) {
    result *= i;
  }
  return result;
}

使用尾调用优化（TCO）

尾调用优化是指：当函数的最后一步是调用自身（且不依赖返回值做额外计算）时，引擎可以复用当前栈帧，从而避免栈深度增长。部分引擎（如 Safari）支持 TCO：

// 非尾调用：需要保存中间结果，无法优化
function factorial(n) {
  if (n <= 1) return 1;
  return n * factorial(n - 1); // 最后一步是乘法，不是调用自身
}

// 尾调用形式：最后一步直接返回递归调用
function factorialTail(n, acc = 1) {
  if (n <= 1) return acc;
  return factorialTail(n - 1, n * acc); // 最后一步是调用自身
}

注意 ：Chrome 和 Node.js 目前尚未完整实现 TCO，因此不能完全依赖它来避免栈溢出。在跨平台项目中，迭代方案更稳妥。

使用「显式栈」替代系统调用栈

对于某些必须用递归的场景（如树的遍历），可以手动维护一个栈来模拟递归过程，从而避免系统调用栈的深度限制：

// 递归遍历二叉树（深度大时可能溢出）
function sumTreeRecursive(node) {
  if (!node) return 0;
  return node.value + sumTreeRecursive(node.left) + sumTreeRecursive(node.right);
}

// 显式栈遍历（不会栈溢出）
function sumTreeIterative(root) {
  let sum = 0;
  const stack = [root];
  
  while (stack.length > 0) {
    const node = stack.pop();
    if (!node) continue;
    sum += node.value;
    stack.push(node.left, node.right);
  }
  return sum;
}

限制递归深度

在无法改写为迭代时，可以主动限制递归深度，在接近栈上限前提前终止：

function safeRecurse(n, depth = 0) {
  if (depth > 10000) {
    throw new Error("递归深度超限，已终止");
  }
  if (n <= 1) return 1;
  return n * safeRecurse(n - 1, depth + 1);
}

实战建议

• 优先选择迭代：在可能的情况下，用循环替代递归。
• 控制递归深度：明确递归的规模上限，避免处理超大数据集。
• 使用尾递归风格：即使引擎不支持 TCO，尾递归风格也更利于未来优化。
• 善用显式栈：处理树、图等结构时，手动维护栈是更可控的方案。

下面是栈溢出的产生过程与应对策略示意图：

flowchart TD A["函数被调用"] --> B["执行上下文压入调用栈"] B --> C{"递归深度是否超过栈上限？"} C -- "否" --> D["继续执行"] D --> B C -- "是" --> E["抛出 RangeError"] E --> F["栈溢出（Stack Overflow）"] F --> G["应对策略"] G --> G1["确保递归有终止条件"] G --> G2["改写为迭代"] G --> G3["使用尾调用优化 TCO"] G --> G4["使用显式栈"] G --> G5["限制递归深度"]

6. 调试方法

6.1 使用浏览器 DevTools 的 Call Stack 面板

在 Chrome DevTools 的 Sources 面板中，当代码在断点处暂停时，右侧的 Call Stack 区域会清晰展示当前调用栈的层级，方便你逐层回溯函数调用关系。

操作步骤

1. 打开 Chrome DevTools（F12 或 Ctrl+Shift+I / Cmd+Option+I）。
2. 切换到 Sources 面板，找到目标 JavaScript 文件。
3. 在代码行号左侧点击，设置断点（Breakpoint）。
4. 刷新页面或触发对应操作，代码会在断点处暂停。
5. 查看右侧 Call Stack 面板，从上到下依次是当前函数、调用它的外层函数，直到全局作用域。

function getUser() {
  debugger; // 在这里暂停，观察 Call Stack
  return { name: "Alice" };
}

function fetchData() {
  const user = getUser();
  console.log(user);
}

fetchData();

当代码暂停时，Call Stack 面板会显示：

fetchData
getUser
(anonymous)

实用技巧

• 点击栈帧跳转：点击 Call Stack 中的任意一层，编辑器会自动跳到对应函数的调用位置，方便查看当时的局部变量。
• 结合 Scope 面板 ：选中某个栈帧后，右侧 Scope 面板会展示该层作用域内的变量值，帮助你判断数据在哪个环节出了问题。
• 使用「Step Over / Step Into」 ：配合 F10（跳过当前行）和 F11（进入函数内部）逐步执行，观察调用栈的实时变化。

6.2 使用 console.trace()

在代码中插入 console.trace()，可以在控制台打印当前调用栈的完整路径：

function a() {
  b();
}

function b() {
  console.trace("当前调用栈：");
}

a();

控制台会输出 a → b 的完整调用链。

输出解读

运行上述代码，控制台会输出类似以下内容：

当前调用栈：
  b
  a
  (anonymous)

每一行代表一个栈帧，最上面是当前正在执行的函数，往下依次是它的调用者。通过这个输出，你可以快速定位「这个函数是被谁调用的」。

实际应用场景

console.trace() 非常适合在以下场景使用：

• 排查「幽灵调用」：某个函数被多处调用，但不确定当前是哪条路径触发的，打印调用栈即可一目了然。
• 调试事件回调 ：事件处理函数往往由框架或浏览器触发，console.trace() 能帮你还原完整的调用链。
• 分析第三方库：当第三方库内部报错时，在调用点打印 trace，可以看清库内部是如何调用你的代码的。

// 示例：多个地方调用同一个函数
function logEvent(type) {
  console.trace(`事件触发：${type}`);
}

// 场景一：按钮点击
button.addEventListener("click", () => logEvent("click"));

// 场景二：定时器
setTimeout(() => logEvent("timeout"), 1000);

与 console.log 的配合

console.trace() 可以结合 console.log 一起使用，先打印变量值，再打印调用栈：

function processOrder(order) {
  console.log("处理订单：", order);
  console.trace("订单处理调用栈：");
  // ... 业务逻辑
}

这样既能看清数据内容，又能知道数据是从哪里传进来的。

6.3 使用 Error 对象的堆栈信息

捕获异常时，error.stack 会包含调用栈信息，便于定位问题源头：

try {
  throw new Error("出错了");
} catch (err) {
  console.log(err.stack);
}

输出解读

运行上述代码，控制台会输出类似以下内容：

Error: 出错了
    at <anonymous>:2:9
    at Object.<anonymous> (<anonymous>:4:3)

error.stack 的第一行是错误信息，后面的每一行都记录了错误发生时的调用位置，包括文件名、行号和列号，方便你快速跳转到出错代码。

在异步代码中定位问题

异步代码（如 Promise、setTimeout）中的错误，堆栈信息同样能帮你还原调用链：

function fetchUser() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      reject(new Error("用户数据加载失败"));
    }, 1000);
  });
}

fetchUser().catch((err) => {
  console.log(err.stack);
});

自定义错误信息

你可以在抛出错误时附加更多上下文信息，让堆栈信息更有价值：

function validateUser(user) {
  if (!user.name) {
    throw new Error(`用户缺少 name 字段，完整数据：${JSON.stringify(user)}`);
  }
  return user;
}

try {
  validateUser({ age: 18 });
} catch (err) {
  console.error(err.stack);
}

实用技巧

• 使用 console.error 代替 console.log ：console.error 在控制台中会以红色显示，并自动附带堆栈信息，更醒目。
• 在全局捕获未处理异常 ：通过 window.onerror 或 process.on('uncaughtException') 捕获未被 try/catch 包裹的错误，记录堆栈便于线上排查。

6.4 使用调试器关键字 debugger

在代码中写入 debugger;，当代码执行到该行时会自动暂停，配合 DevTools 逐步调试：

function calculate(x) {
  debugger; // 执行到这里自动暂停
  return x * 2;
}

与手动设置断点的区别

• 手动断点：需要在 DevTools 中操作，适合调试时临时设置。
• debugger 语句：直接写在代码里，只要 DevTools 处于打开状态，执行到该行就会自动暂停，无需手动操作。

条件调试

你可以把 debugger 放在条件判断中，只在特定情况下暂停：

function processItem(item) {
  // 只在 item 为空时暂停调试
  if (item == null) {
    debugger;
  }
  // ... 业务逻辑
}

processItem({ id: 1 });
processItem(null); // 这里会触发 debugger

在循环中调试

在循环中配合条件使用，可以精准定位到出问题的某一次迭代：

const items = [1, 2, 3, 4, 5];

for (let i = 0; i < items.length; i++) {
  // 只在 i === 3 时暂停
  if (i === 3) {
    debugger;
  }
  console.log(`处理第 ${i} 个元素：${items[i]}`);
}

注意事项

• 生产环境务必移除 ：debugger 语句会阻塞代码执行，上线前一定要删除或通过构建工具自动移除。
• 需要 DevTools 配合 ：如果浏览器 DevTools 未打开，debugger 语句会被忽略，不会影响正常执行。
• 配合 Watch 面板 ：暂停后可以在 DevTools 的 Watch 面板添加表达式，实时观察变量变化。

// 模拟耗时操作 const data = \[\]; for (let i = 0; i < 100000; i++) { data.push(i * 2); }

console.timeEnd("数据处理"); // 输出：数据处理: 3.2ms

#### 对比不同实现方案的性能

```javascript
// 方案一：使用 for 循环
console.time("for 循环");
let sum1 = 0;
for (let i = 0; i < 1000000; i++) {
  sum1 += i;
}
console.timeEnd("for 循环");

// 方案二：使用 reduce
console.time("reduce");
const arr = Array.from({ length: 1000000 }, (_, i) => i);
const sum2 = arr.reduce((acc, cur) => acc + cur, 0);
console.timeEnd("reduce");

通过对比输出耗时，你可以直观地判断哪种实现更高效。

嵌套计时

console.time() 支持嵌套使用，可以分别测量外层和内层代码的耗时：

console.time("整体任务");

console.time("步骤一：数据获取");
// 模拟数据获取
setTimeout(() => {
  console.timeEnd("步骤一：数据获取");

  console.time("步骤二：数据处理");
  // 模拟数据处理
  const result = [1, 2, 3].map((n) => n * 2);
  console.timeEnd("步骤二：数据处理");

  console.timeEnd("整体任务");
}, 500);

下面是本章介绍的五种调试方法对比图：

flowchart TD A[&#34;调试方法&#34;] --> B[&#34;DevTools Call Stack 面板&#34;] A --> C[&#34;console.trace()&#34;] A --> D[&#34;Error 对象堆栈信息&#34;] A --> E[&#34;debugger 关键字&#34;] B --> B1[&#34;断点暂停时查看调用栈层级&#34;] C --> C1[&#34;控制台打印完整调用链&#34;] D --> D1[&#34;捕获异常时定位问题源头&#34;] E --> E1[&#34;代码执行到该行自动暂停&#34;]

7. 总结

• 执行上下文 是代码运行的环境抽象，分为全局、函数和 eval 三种。
• 变量环境 存放 var 与函数声明，存在变量提升；词法环境 存放 let/const，存在暂时性死区。
• 调用栈 以 LIFO 方式管理函数调用，栈溢出通常由无限递归引起。
• 掌握 console.trace()、debugger、DevTools Call Stack 面板等调试手段，能大幅提升定位问题的效率。

理解执行上下文与调用栈，是深入 JavaScript 运行机制的第一步。希望本文能帮你建立起清晰的认知框架，在后续的异步编程、闭包与事件循环学习中更加游刃有余。