JavaScript执行上下文与调用栈：从原理到面试题深度解析

1. 面试被问“执行上下文”时，大多数人到底答了什么

面试官问出“说说你对JavaScript执行上下文的理解”，我见过太多这样的回答：执行上下文就是代码执行的环境，分为全局、函数和eval三种，执行时会创建变量对象、作用域链和this。然后就没了。

这个答案错吗？不算错，但也就值20分。因为这只是背诵的框架，真正有价值的不是“执行上下文是什么”，而是它怎么参与一段代码从解析到执行的完整过程，以及它和调用栈、作用域链、闭包、this绑定这些让无数人头疼的概念之间到底是什么关系。

先看一个最典型的例子：

javascript复制var a = 1;
function foo() {
  console.log(a);
  var a = 2;
}
foo();

很多学过变量提升的人知道答案是undefined，但如果继续追问：为什么是undefined而不是1？console.log(a)执行时，引擎是怎么找到a这个变量的？这时候大部分人就卡壳了。

要回答清楚这个问题，就必须从执行上下文和调用栈的机制层面来理解。这也是我写这篇文章的原因——把执行上下文、调用栈这些JS引擎层面的机制，配合面试题逐个拆开，让脑子里对这些概念形成一个具体的“动态过程画面”，而不是一堆需要背诵的名词。

这篇文章适合谁看？正在准备前端面试的人、学完JS语法但总是被闭包和this卡住的人，以及写了两年业务代码但从来没真正搞懂运行时机制的人。文章不会涉及复杂的编译原理，只讲和日常开发、面试强相关的部分。

2. 从“环境快照”到执行上下文栈：代码运行前发生了什么

2.1 执行上下文其实是代码运行的“现场环境”

先忘掉教科书式的定义，用个类比帮助理解。

你打开一个浏览器标签页，在里面做一件事，这件事需要一些前置条件：当前页面地址、登录状态、表单里已经填了一半的内容。你做的每一步操作，都基于这个“现场环境”。在JavaScript中，执行上下文就是代码运行时的“现场环境”——它决定了一段代码能访问哪些变量、函数，以及代码里this指向什么。

关键点在于：执行上下文不是代码本身，而是引擎在执行代码前构建的一个内部对象。 每段可执行的JavaScript代码，在真正开始“逐行跑”之前，引擎先把这个上下文准备好。

那么一段JavaScript代码的执行流程是这样的：

1. 引擎读取JavaScript代码后，先进行语法分析（Parsing），生成抽象语法树（AST）。
2. 当某段代码准备执行时，引擎创建对应的执行上下文，并压入执行上下文栈（也叫调用栈）。
3. 执行上下文进入创建阶段：建立词法环境、变量环境、确定this绑定。
4. 执行阶段：逐行运行代码，为变量赋值，调用函数时再次触发新上下文的创建。

注意第2步和第3步的顺序：上下文创建后，会先经历一个“准备阶段”，然后才真正执行代码。 这个准备阶段，就是变量提升、函数声明提升、this绑定这些行为发生的时刻。

2.2 三种类型的执行上下文

JavaScript有且仅有三种执行上下文：

• 全局执行上下文（Global Execution Context）：程序启动时创建，且只有一个。浏览器环境下，全局上下文内的this指向window对象；Node.js环境中则指向global。
• 函数执行上下文（Function Execution Context）：每次函数被调用（注意，是调用，不是定义）时创建。一个函数每次被调用，都会产生一个全新的执行上下文。
• eval执行上下文：在eval函数中执行代码时创建。这个在日常开发中基本应该避免使用，这里不展开。

这三种上下文之间的关系，可以通过“执行上下文栈”来管理。

2.3 执行上下文栈：后进先出，和函数返回的顺序严格一致

执行上下文栈（Execution Context Stack），在开发工具里经常被称为调用栈（Call Stack）。它的规则很简单：后进先出（LIFO）。

看这段代码：

javascript复制function foo() {
  console.log('foo');
  bar();
}
function bar() {
  console.log('bar');
}
foo();

整个过程的上下文变动如下：

1. 全局代码执行前，引擎创建全局执行上下文，压入栈底。
2. 调用foo()时，引擎创建foo的函数执行上下文，压入栈顶。
3. foo内部调用bar()，引擎创建bar的函数执行上下文，压入栈顶。
4. bar执行完毕，它的执行上下文从栈顶弹出，控制权交回foo。
5. foo执行完毕，它的执行上下文弹出，控制权交回全局代码。
6. 页面关闭或程序退出时，全局执行上下文销毁。

这里有一个非常重要的认知：调用栈的弹出顺序，就是函数执行的完成顺序。 如果某个函数内部又调用了其他函数，内层函数必须完全执行完成，外层函数才能继续往下走。这一点在分析异步代码、递归、栈溢出时有决定性的作用。

2.4 栈溢出的根源：上下文栈是有限空间的

写递归时经常遇到的RangeError: Maximum call stack size exceeded，就是执行上下文栈被塞满导致的。每调用一层递归，引擎就向栈中压入一个新的函数执行上下文；如果递归没有终止条件，上下文会不停入栈，最终超出栈的容量上限。

以一个简单递归为例：

javascript复制function recurse(num) {
  return recurse(num + 1);
}
recurse(0);

这段代码会在几毫秒内爆栈，因为每一层递归都要创建新的执行上下文，而栈的空间是有限的（具体上限因浏览器引擎而异，但是是固定的）。

注意：栈溢出导致程序崩溃，但不会导致浏览器整体卡死。因为第3版之后的现代浏览器为每个页面分配了独立的渲染进程和线程，栈溢出只会影响到当前页面的脚本执行。

3. 创建上下文时引擎偷偷做了三件事：词法环境、变量环境和this绑定

3.1 创建阶段的三个动作

每次创建执行上下文，引擎会依次完成三个核心任务。理解这三件事，是理解变量提升、块级作用域、闭包、this绑定的前提：

1. 创建词法环境（Lexical Environment）：用于存储let、const声明的变量和函数声明，并登记对外部环境的引用（即outer）。
2. 创建变量环境（Variable Environment）：用于存储var声明的变量和函数声明。注意，var变量在初始阶段就被设为undefined，这一步也是变量提升的真正原因。
3. 确定this绑定（The Binding This）：根据函数的调用方式确定this的值。

词法环境和变量环境看起来是两套机制，很多教材把它们统称为“环境记录”。为什么引擎非要做成两个？核心原因是：var和let/const的行为差异太大，前者需要提升并初始化为undefined（这样即使声明前访问也不会报错），后者则要求在初始化前访问会报错（暂时性死区）。如果混在一起，引擎在处理块级作用域和声明提升时会非常混乱。

3.2 变量提升和函数声明提升：为什么var能“提前用”

看这段代码：

javascript复制console.log(a);       // undefined
var a = 10;

执行过程是这样的：创建全局执行上下文时，变量环境被创建，引擎扫描到var a = 10这个声明，将a登记进变量环境，并初始化为undefined。然后执行阶段，逐行运行代码：执行console.log(a)时，从变量环境中查到a的值是undefined；接着执行a = 10，把a的值更新为10。所以打印出undefined。

函数声明的提升更“彻底”：

javascript复制console.log(foo());   // 'foo executed'
function foo() {
  return 'foo executed';
}

因为函数声明在创建阶段就会被完整地声明并赋值给变量foo，所以即使在函数定义之前调用，也能正常执行。

但要注意，函数表达式的提升方式不同：

javascript复制console.log(bar());   // TypeError: bar is not a function
var bar = function() {
  return 'bar';
};

这里var bar被提升并初始化为undefined，而undefined不是函数，所以调用时报错。如果把var改成let，则会直接报ReferenceError（因为暂时性死区），后续再讲。

3.3 词法环境与暂时性死区：let和const为何如此“严格”

let、const声明的变量，在创建阶段也会被登记到词法环境，但是不会被初始化。从进入作用域开始，到变量声明被执行之间的这段区间，访问该变量会直接抛出ReferenceError。这个区间就是传说中的暂时性死区（TDZ）。

javascript复制console.log(x);   // ReferenceError: Cannot access 'x' before initialization
let x = 10;

为什么JS引擎非要这么设计？简单说，为了“更安全”。var的变量提升会让变量在声明前以undefined存在，程序员容易写出依赖了“意外提升”的代码，但又不易察觉。let/const的TDZ设计，强制你在声明后才能访问，从机制上堵住了这种隐性错误的来源。

实际开发中，这个特性还有一个隐蔽的坑：

javascript复制var a = 1;
if (true) {
  console.log(a);   // ReferenceError
  let a = 2;
}

很多初学者以为这里的a会输出全局的1，因为块内let a的声明还没执行到。但实际上，当进入if代码块这个块级作用域时，引擎就已经把块内的let a登记进了当前词法环境，同时进入TDZ。所以在let a = 2执行之前访问，报错。这也说明：TDZ的范围是“从进入作用域到声明执行”，而不是“只是声明那一行”。

3.4 this绑定：为什么this不遵守作用域链规则

this是执行上下文创建阶段确定的，但它的确定规则比较特殊：它不依赖词法作用域，而是依赖函数被调用时的方式（call site）。

JS中this的绑定规则大致有四条：

优先级从低到高是：默认 < 隐式 < 显式 < new。

其中最容易出问题的是隐式绑定“丢失”：

javascript复制const obj = {
  name: 'obj',
  getName: function() {
    return this.name;
  }
};
const fn = obj.getName;
console.log(fn());   // 非严格模式：undefined（this指向window，window上没有name）
console.log(obj.getName());  // 'obj'

当obj.getName被赋值给fn后再调用，调用点变成了fn()，已经和obj无关，所以this走默认绑定，指向全局对象。这背后正是执行上下文创建阶段确定this的机制——引擎只看“函数在哪里被调用”，不看“函数在哪里被定义”。

4. 作用域链是执行上下文之间的一条“隐形连线”

4.1 outer引用：每个环境都记着自己的“出生地”

刚才提到词法环境会登记一个对外部环境的引用，这个引用就是outer（也叫外部环境引用）。它的值，是创建该函数时的词法环境（而不是调用时的环境）。

看一个很典型的例子：

javascript复制var x = 'global';
function a() {
  var y = 'in a';
  function b() {
    console.log(x);  // global
    console.log(y);  // in a
  }
  b();
}
a();

函数b定义时，它所在的词法环境是a函数内部的词法环境（包含了y）。所以b内部环境的outer引用指向的就是a的词法环境；a的词法环境的outer引用指向全局环境。当引擎在b内部执行console.log(x)时，当前环境的记录里找不到x，就顺着outer引用去a的环境里找，还是找不到，再顺着a的outer去全局环境找，找到了x = 'global'。

这条“顺着outer引用一层层向外查找变量”的链路，就是作用域链（Scope Chain）。

4.2 闭包的底层逻辑：函数带着“出生环境”一起走

闭包是执行上下文和词法环境结合后自然生长出来的结果。

在正常情况下，函数执行完毕，其执行上下文会从调用栈中弹出，内部的变量环境、词法环境也应该被销毁。但是如果某个内部函数被返回出来，并且这个内部函数持有了外部函数词法环境的引用（outer），那么即使外部函数的执行上下文已经弹出，它的词法环境依然会被引擎保留，因为内部函数还“指着”它。

javascript复制function outer() {
  let count = 0;
  return function inner() {
    count++;
    return count;
  };
}
const counter = outer();
console.log(counter());  // 1
console.log(counter());  // 2

outer执行完毕后，本应释放的count变量并没有消失，因为内部函数inner的词法环境的outer引用指向了outer的词法环境。counter每次调用，都会在这个被保留的环境里修改count的值。这就是闭包的内存原理，也是“闭包会占用内存”这一说法的来源——被保留的环境不会轻易被回收。

4.3 作用域链和调用栈的经典混搭题：通过上下文图推答案

把作用域链和执行上下文栈结合起来看一道经典题：

javascript复制function outer() {
  var a = 1;
  function inner() {
    console.log(a);
  }
  return inner;
}
var a = 100;
var fn = outer();
fn();   // 输出什么？

输出是1，不是100。原因在于：inner内部查找a时，顺着outer引用找到的是定义它的outer词法环境，那里有a = 1；虽然调用fn()时的全局环境里也有a = 100，但作用域链在函数定义时就定死了，不会因为调用位置而改变。这里的fn()的调用栈中，虽然全局上下文在栈底，但inner的outer指向的并不是当前调用栈栈底的全局上下文，而是创建它时的那个词法环境。

这张图就是理解这类题的关键：变量查找走的是词法环境之间的outer链，不是调用栈的栈帧链。 两者是两套完全不同的机制，调用栈管“函数执行顺序”，作用域链管“变量查找路径”。

5. 面试题实战：从执行上下文推导答案，而不是背结论

这一节把前四节讲的内容串起来，用5道高频面试题来验证理解。每一题都会给出完整的推导过程，而不是只说“最后输出什么”。

5.1 变量提升和函数提升的优先级问题

javascript复制function foo() {
  console.log(typeof a);
  var a = 1;
  function a() {}
}
foo();

输出是什么？不看答案会比较容易答错，但按执行上下文的创建阶段分析很清晰。

foo执行上下文的创建阶段，变量环境扫描到两个声明：var a和function a。关键规定是：函数声明优先。所以先登记function a，值为整个函数；再处理var a时，因为a已经被登记过了，var不会覆盖，所以保持函数。执行阶段第一行console.log(typeof a)读到的就是function。后续a = 1才会把a覆盖成数字。

这类题的通用解法是：写代码时把变量提升和函数提升“平移”到作用域顶部，函数在前，var在后，再去跑结果。

5.2 for循环的setTimeout经典闭包问题

javascript复制for (var i = 0; i < 5; i++) {
  setTimeout(() => {
    console.log(i);
  }, 0);
}

输出的是5 5 5 5 5。为什么会这样？套用执行上下文的视角来看：

for循环本身不会创建新的执行上下文，var i被提升到全局环境（或函数环境），也就是说这五个箭头函数共享同一个i变量。setTimeout的回调函数会在i循环结束后才执行（宏任务机制），那时i已经是5，所以每个回调访问到的都是5。

改为let：

javascript复制for (let i = 0; i < 5; i++) {
  setTimeout(() => {
    console.log(i);
  }, 0);
}

输出变成0 1 2 3 4。原因：let的每次迭代都会创建一个新的块级词法环境，当前这一轮的i被绑定在本次迭代的块级环境里。每个回调函数都持有自己那一轮迭代的i环境引用（闭包机制），所以打印的值分别是0、1、2、3、4。

这个点很常被问到，细节上可以看这样：并非setTimeout变了，而是let改变了每个回调函数绑定到的词法环境。

5.3 利用调用栈推this指向

javascript复制const obj = {
  name: 'obj',
  getName: function() {
    return this.name;
  }
};

function logName(callback) {
  console.log(callback());
}

logName(obj.getName);

输出是什么？undefined或报错（严格模式下this为undefined访问name会TypeError）。因为在logName内部调用的是callback()，调用点是一个普通函数调用，不是obj.getName()，所以this走默认绑定。至于为什么不是obj——在执行上下文创建阶段，this的确定规则就是看调用方式，这里调用时没有指定对象，和函数从哪里取出来的无关。

但是换成这样就会不一样：

javascript复制logName(obj.getName.bind(obj));   // 'obj'

通过bind显式绑定，callback()执行时this仍然指向obj。这就是显式绑定的优先级高于默认绑定。

5.4 暂时性死区与函数默认参数

javascript复制let x = 1;
function foo(x = x) {
  return x;
}
console.log(foo());

这里会报ReferenceError: Cannot access 'x' before initialization。原因是函数默认参数拥有自己独立的词法作用域，参数名x在初始化时引用了它自身，此时x还没有绑定值，落入TDZ。在创建foo的函数执行上下文时，引擎会先初始化参数环境，参数x的值等于表达式x的结果，但此时这个x是自己，尚未完成初始化，所以访问报错。这属于“作用域重名 + TDZ”的经典组合。

如果改成function foo(y = x)，就不会报错，而是输出1。因为y初始化时访问的x是外层词法环境中的那个x = 1。

5.5 结合调用栈分析递归爆栈前的执行顺序

最后稍微进阶一点的面试题：

javascript复制function factorial(n) {
  if (n === 1) return 1;
  return n * factorial(n - 1);
}
console.log(factorial(5));

面试一般不直接考这道题，而是会问：“整个调用过程中，调用栈最多同时存在几个执行上下文？”答案是5个，因为factorial(5)调用factorial(4)，后者调用factorial(3)……直到factorial(1)返回之前，调用栈里有多达5个factorial函数的执行上下文，加上全局上下文共6层。从factorial(1)返回后，才一层层地计算结果：1、2、6、24、120。

顺着这个思路，如果再追问“如果n很大，比如10000，会发生什么”，答案是爆栈。因为每层递归都要占用一个上下文栈位置，栈空间有限。而尾调用优化（如果环境支持的话）可以在某些场景下让递归不增加栈深度，但JavaScript的尾调用优化在主流浏览器中支持状况并不理想，不能完全依赖它。

6. 理解执行上下文和调用栈在实际调试中的作用

最后补充一些和实际开发结合的经验，毕竟面试题考的是机制，而机制最终是要帮助解决问题。

6.1 浏览器DevTools的调用栈面板

当你在console中打一个debugger断点，或者代码抛出异常时，调用栈面板展示的就是当前执行上下文栈的状态。栈顶是当前正在执行的函数，下面的每一帧是对应着一个个正在等待返回的函数执行上下文。你可以点击任何一帧，查看该帧内部的作用域变量值。这个工具用熟了，排查递归逻辑错误、事件回调里的变量被意外修改、闭包状态不对等问题时会快很多。

注意一个细节：DevTools的Scope面板里会展示Closure（闭包）一栏。那里面就是你通过outer引用链接到的、当前函数可访问的词法环境。多看这个面板，对“闭包不是抽象概念，而是实实在在的环境记录”会有更直观的感受。

6.2 变量查找的性能教训

因为变量查找是顺着作用域链一层层往外走的，所以“嵌套深度越深，查找越慢”。虽然现代JavaScript引擎做了很多优化（比如基于隐藏类、内联缓存来加速属性访问），但依然不要写出层数过深的嵌套函数。比如：

javascript复制function level1() {
  var a = 1;
  function level2() {
    var b = 2;
    function level3() {
      console.log(a + b);  // 引擎要一路从level3查到level2再查到level1
    }
    level3();
  }
  level2();
}
level1();

这类代码可读性差，运行效率也会受到影响。日常开发中，把嵌套控制在一两层内，是对维护性、可读性、性能都友好的做法。

6.3 结合执行上下文规避常见的内存泄漏

既然闭包会保留词法环境，在写代码时就要小心“随手产生的闭包意外延续生命周期”。一个很常见的场景：

javascript复制function attachEventListener() {
  const largeData = new Array(1000000).fill('x');
  document.getElementById('btn').addEventListener('click', function() {
    console.log('clicked');
  });
}

看起来这个回调函数没有用largeData，但由于它定义在attachEventListener的词法环境中，引擎无法判断你将来会不会用，因此largeData会被保留。如果这样的监听器不会被移除，这份大数组就变成了长期内存占用。

解决思路不外乎两种：在回调外部手动将largeData置为null，或者尽量在不需要时移除事件监听器。这背后其实都是对“词法环境生命周期”的理解——一个环境被谁引用着，它就不会被回收。

我在实际开发中遇到过类似的问题累积起来导致页面越来越卡，最后查出来的原因是某个被反复挂载卸载的组件里，事件监听器的回调一直带着创建时的组件实例环境，实例里又缓存了大量图片数据。后来排查时就重点检查了闭包环境、监听器的移除时机，问题很快解决。

7. 最后的建议和一道自测题

学习执行上下文和调用栈这类运行时机制，核心方法就一个：不要背结论，试着“在脑子里跑代码”。每次遇到一段JS代码，先想清楚这句代码会导致几个执行上下文入栈、每个上下文的创建阶段做了什么、执行阶段做了什么、栈怎么弹出。坚持一段时间，变量提升、作用域、闭包、this这四个拦路虎会被同时消灭。

最后留一道综合自测题，把本文讲到的机制全部串起来。可以试着按照执行上下文创建、调用栈进出、作用域链查找的顺序一步步推，再打开浏览器验证：

javascript复制var x = 10;
function outer() {
  var x = 20;
  function inner() {
    console.log(x);
    console.log(this.x);
  }
  return inner;
}
var obj = {
  x: 30,
  method: outer()
};
obj.method();

推完再跑一下，如果你每一步都对得上，说明执行上下文和调用栈这块已经真正打通了。如果还差一点，就回到文章里对应的章节再看一遍，尤其注意作用域链和this绑定是两套独立机制这一点。