什么是JS的运行上下文？

执行上下文是JS代码执行时的环境，包含变量、函数和this指向。它分为全局和函数执行上下文，前者在脚本加载时创建，后者在函数调用时创建并入栈，形成执行栈。每个上下文有创建和执行两阶段：创建阶段确定this、提升变量、建立作用域链；执行阶段赋值变量并执行代码。全局上下文this指向window或global，函数上下文this取决于调用方式。通过作用域链，内层函数可访问外层变量，支持闭包机制。理解执行上下文有助于掌握作用域、闭包、this指向及调试优化。

JavaScript的运行上下文，简单来说，就是JS代码执行时所处的“环境”。它是一个抽象概念，包含了代码执行所需的一切信息，比如当前作用域内的变量、函数、

this

的指向等等。每次我们执行一段JS代码，无论是全局脚本还是函数调用，都会创建一个对应的运行上下文。

每次JavaScript引擎执行代码时，都会创建一个执行上下文。这就像给代码搭建了一个临时的“舞台”，上面摆放着所有演出所需的道具和演员。理解这个机制，对于我们前端开发者来说，简直是拨开迷雾见青天，很多看似玄妙的JS行为，比如作用域链、闭包、

this

的指向，都能找到清晰的解释。

执行上下文主要有两种：全局执行上下文（Global Execution Context, GEC）和函数执行上下文（function Execution Context, FEC）。当浏览器加载JS文件时，首先会创建一个全局执行上下文，它就是最外层的舞台。所有不在任何函数内部的代码，都在这个全局上下文中运行。在这个环境中，

this

通常指向

window

对象（在浏览器中）或

global

对象（在node.js中）。

而每当我们调用一个函数，JavaScript引擎就会为这个函数创建一个新的函数执行上下文，并将其推入执行栈（Call Stack）的顶部。这个新的上下文有自己的变量环境和

this

绑定。当函数执行完毕，它的上下文就会从栈中弹出，控制权回到前一个上下文。这个过程周而复始，构成了我们JS代码执行的动态流程。

每个执行上下文内部，都包含几个关键组件：

• 变量环境（variable Environment）或称词法环境（Lexical Environment）：这玩意儿是核心。它存储了在该上下文中定义的变量、函数声明以及函数参数。它又包含两部分：
  • 环境记录（Environment Record）：实际存储变量和函数声明的地方。它知道

    var

    、

    let

    、

    const

    声明的变量，以及函数声明。对于

    var

    和函数声明，在上下文创建阶段就已经被“记录”下来了（这就是所谓的变量提升和函数提升）。而

    let

    和

    const

    则会进入一个“暂时性死区”（Temporal Dead Zone, TDZ），直到它们被实际声明的那一行代码执行到。

  • 外部环境引用（Outer Environment Reference）：这是一个指针，指向它的父级词法环境。正是这个引用，构建起了作用域链，让内部函数可以访问外部函数的变量。

• this

  绑定（This Binding）：明确当前上下文中

  this

  关键字指向谁。它的值完全取决于函数被调用的方式，这可是个老生常谈的痛点，也是理解执行上下文后能豁然开朗的关键。

可以说，执行上下文就是JS引擎在幕后默默为你搭建的舞台，它决定了你的代码能看到什么，能访问什么，以及“我”是谁（

this

）。

为什么理解执行上下文对前端开发者至关重要？

作为一名混迹前端多年的老兵，我深知很多初学者，甚至是一些有经验的开发者，在面对JavaScript中一些“奇怪”的行为时，常常感到困惑。比如，为什么这个

this

指向的不是我想要的？为什么我的变量在函数外面也能被访问，或者反过来，为什么它就访问不到？这些问题的根源，往往都指向对执行上下文理解的不足。

首先，它直接解释了作用域链和闭包的原理。当我们谈论作用域，我们其实在谈论的是变量环境的外部环境引用。一个函数在创建时，它的词法环境就已经确定了，这个环境包含了它定义时的父级作用域。即使外部函数执行完毕，其上下文被销毁，但如果内部函数（闭包）还存在，并且引用了外部作用域的变量，那么外部作用域的词法环境就不会被垃圾回收，而是继续被闭包“捕获”着。这正是闭包能够记住并访问其外部作用域变量的秘密。不理解这一点，你写闭包就只能靠“感觉”，而不是清晰的设计。

其次，它彻底揭示了

this

关键字的动态行为。

this

在JavaScript里是个出了名的“多变郎君”。在全局上下文里，它通常是

window

；在普通函数调用里，它可能还是

window

（非严格模式下）；但作为对象方法调用时，它又指向了那个对象；如果用

call

、

apply

、

bind

，那更是可以随意指定。这些“变脸”的背后，正是执行上下文在创建阶段进行

this

绑定的结果。当你清楚地知道当前代码运行在哪个上下文，以及这个上下文的

this

是如何被绑定的，那么

this

的指向就不再是谜团，而是一个可预测的机制。这对于编写健壮、可维护的面向对象JS代码至关重要。

再者，它能让你更有效地调试代码。当你在浏览器开发者工具中设置断点，你会发现Scope（作用域）面板会显示当前的Local（本地）变量和Closure（闭包）变量。这些正是当前执行上下文和其外部词法环境所包含的信息。理解执行上下文，能让你在调试时，清晰地知道当前作用域内有哪些变量可用，以及它们的值是什么，为什么某个变量没有被找到，或者为什么它的值不是你预期的。这大大提升了调试效率，让你从“大海捞针”变为“按图索骥”。

最后，从更深层次看，它帮助我们写出更优化的代码。虽然不是直接的性能优化点，但对执行上下文的理解，能让我们在设计模块、组织代码时，更清晰地思考变量的生命周期和作用域范围。比如，避免不必要的全局变量污染，合理利用闭包管理私有状态，这些都间接有助于减少内存占用，提高代码的健壮性和可维护性。

执行上下文的生命周期是怎样的？

一个执行上下文的生命周期可以大致分为两个主要阶段：创建阶段和执行阶段。这两个阶段是JS引擎在幕后默默完成的，但理解它们对于我们理解JS的运行时行为至关重要。

1. 创建阶段（Creation Phase）

当JavaScript引擎准备执行一段代码（无论是整个脚本还是一个函数调用）时，它不会立刻执行，而是先进入一个“准备”阶段，即创建阶段。在这个阶段，执行上下文会被初始化，但代码还没有真正运行。这个阶段主要做了三件事：

• 确定

  this

  的绑定（This Binding）：

  • 对于全局执行上下文，

    this

    会被绑定到全局对象（浏览器中是

    window

    ，Node.js中是

    global

    ）。

  • 对于函数执行上下文，

    this

    的绑定则复杂得多，它取决于函数是如何被调用的：是作为对象的方法调用？是普通函数调用？是使用

    call

    /

    apply

    /

    bind

    显式调用？还是通过

    new

    关键字构造函数？在这个阶段，

    this

    的值就已经被确定下来了。

• 创建词法环境（Lexical Environment Component）：
  • 环境记录（Environment Record）：这是存储变量和函数声明的地方。
    • 对于

      var

      声明的变量和函数声明，它们会被“提升”（Hoisting）到当前上下文的顶部，并在此时被初始化。

      var

      变量会被初始化为

      undefined

      ，函数声明则直接存储其函数定义。

    • 对于

      let

      和

      const

      声明的变量，它们也会被记录下来，但不会被初始化，而是进入“暂时性死区”（Temporal Dead Zone, TDZ）。这意味着在代码执行到它们声明的那一行之前，尝试访问它们会抛出

      ReferenceError

      。

  • 外部环境引用（Outer Environment Reference）：这个引用被设置指向创建当前上下文的那个词法环境。比如，一个函数在哪个作用域被定义，它的外部环境引用就指向那个作用域的词法环境。这构成了作用域链。
• 创建变量环境（Variable Environment Component）：在es6之前，变量环境和词法环境基本是同一个概念。ES6引入

  let

  和

  const

  后，词法环境变得更精细，它现在包含了一个“环境记录”，可以区分

  var

  /函数声明和

  let

  /

  const

  声明。简单来说，变量环境是词法环境的一个子集，主要处理

  var

  和函数声明。但为了简化理解，通常可以把它们看作是负责管理变量和函数声明的那个部分。

2. 执行阶段（Execution Phase）

当创建阶段完成后，JavaScript引擎就开始逐行执行代码了。在这个阶段：

• 变量赋值：之前在创建阶段被初始化为

  undefined

  的

  var

  变量，现在会被赋予它们在代码中实际指定的值。

  let

  和

  const

  变量也会在它们声明的那一行被初始化并赋值。

• 函数调用：当代码执行到函数调用时，一个新的函数执行上下文会被创建，并重复上述的创建阶段和执行阶段。这个新的上下文会被推入执行栈的顶部。
• 代码逻辑：所有的表达式、语句都会被求值和执行。

当一个函数执行完毕（遇到

return

语句或执行到函数末尾），它的函数执行上下文就会从执行栈中弹出。如果这个上下文不再被任何闭包引用，那么它所占用的内存就会被垃圾回收机制回收。全局执行上下文则会一直存在，直到浏览器窗口关闭或Node.js进程退出。

全局执行上下文与函数执行上下文有什么不同，以及它们如何交互？

全局执行上下文（Global Execution Context, GEC）和函数执行上下文（Function Execution Context, FEC）是JavaScript中两种最基本的执行上下文类型，它们既有显著区别，又通过执行栈和作用域链紧密交互，共同构成了代码的运行时环境。

主要区别：

1. 创建时机与数量：
   • GEC：当JavaScript代码首次加载到浏览器或Node.js环境中时，GEC就会被创建。一个JS程序在任何时刻都只有一个GEC，它是所有其他上下文的基石。
   • FEC：每当一个函数被调用时，就会创建一个新的FEC。这意味着，一个程序中可以有任意数量的FEC，甚至同一个函数被调用多次，也会创建多个独立的FEC。

2. this

   的绑定：

   • GEC：在浏览器环境中，GEC的

     this

     通常指向

     window

     对象。在Node.js环境中，它指向

     global

     对象。

   • FEC：FEC的

     this

     绑定是动态的，它取决于函数被调用的方式。例如，作为对象方法调用时指向该对象；普通函数调用（非严格模式）时指向

     window

     /

     global

     ；使用

     call

     /

     apply

     /

     bind

     时指向指定对象；使用

     new

     关键字时指向新创建的实例。

3. arguments

   对象：

   • GEC：不包含

     arguments

     对象。

   • FEC：每个FEC都会自动获得一个

     arguments

     对象，它是一个类数组对象，包含了函数被调用时传入的所有参数。

4. 作用域范围：
   • GEC：提供了最外层的全局作用域。在GEC中声明的变量和函数可以在程序的任何地方被访问（除非被同名局部变量遮蔽）。
   • FEC：为函数创建了一个独立的局部作用域。在FEC中声明的变量和函数，默认只能在该函数内部访问，外部无法直接访问。

它们如何交互？

GEC和FEC之间的交互主要通过执行栈（Call Stack）和作用域链（Scope Chain）来实现：

1. 执行栈（Call Stack）的组织：

   • GEC始终位于执行栈的最底部。它是JS程序的起点和终点。
   • 当一个函数被调用时，一个新的FEC被创建并推入执行栈的顶部。
   • 当这个函数执行完毕后，它的FEC会从栈中弹出，控制权回到栈中下一个（通常是调用它的）上下文。
   • 这种LIFO（后进先出）的机制，决定了代码的执行顺序。

      let globalVar = 'I am global'; // 在GEC中

   function outer() { // outer()的FEC let outerVar = ‘I am outer’; console.log(globalVar); // 访问GEC的变量

   function inner() { // inner()的FEC     let innerVar = 'I am inner';     console.log(outerVar); // 访问outer()的变量     console.log(globalVar); // 访问GEC的变量 } inner(); // 调用inner()，创建inner的FEC并推入栈

   }

   outer(); // 调用outer()，创建outer的FEC并推入栈 // 整个脚本执行完毕，GEC从栈中弹出（浏览器关闭或进程结束）

    在这个例子中，`outer`函数调用时，其FEC被推入栈，`inner`函数调用时，其FEC再被推入栈。当`inner`执行完弹出，`outer`执行完弹出，最后只剩下GEC。

2. 作用域链（Scope Chain）的构建：

   • 每个执行上下文的词法环境都有一个

     Outer Environment Reference

     ，指向它的父级词法环境。

   • GEC的

     Outer Environment Reference

     通常为

     NULL

     ，因为它没有外部作用域。

   • FEC的

     Outer Environment Reference

     指向它被定义时所在的作用域的词法环境。

   • 通过这些引用，JavaScript引擎在查找变量时，会沿着这条链条一层一层地向外查找，直到找到变量或到达GEC。这就是作用域链，它决定了变量的可访问性。
   • 这种机制使得内层函数可以访问外层函数甚至全局作用域的变量，但外层函数无法直接访问内层函数的局部变量。

这种分层且相互关联的上下文机制，是JavaScript灵活而强大的基础。它允许我们组织模块化的代码，同时又能在需要时进行跨作用域的数据共享，比如通过闭包实现私有变量和模块模式。理解这些交互，是掌握JS高级特性和避免常见陷阱的关键。