执行上下文是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中两种最基本的执行上下文类型，它们既有显著区别，又通过执行栈和作用域链紧密交互，共同构成了代码的运行时环境。
主要区别：
创建时机与数量：GEC：当JavaScript代码首次加载到浏览器或Node.js环境中时，GEC就会被创建。一个JS程序在任何时刻都只有一个GEC，它是所有其他上下文的基石。FEC：每当一个函数被调用时，就会创建一个新的FEC。这意味着，一个程序中可以有任意数量的FEC，甚至同一个函数被调用多次，也会创建多个独立的FEC。
this
的绑定：GEC：在浏览器环境中，GEC的
this
通常指向
window
对象。在Node.js环境中，它指向
global
对象。FEC：FEC的
this
绑定是动态的，它取决于函数被调用的方式。例如，作为对象方法调用时指向该对象；普通函数调用（非严格模式）时指向
window
/
global
；使用
call
/
apply
/
bind
时指向指定对象；使用
new
关键字时指向新创建的实例。
arguments
对象：GEC：不包含
arguments
对象。FEC：每个FEC都会自动获得一个
arguments
对象，它是一个类数组对象，包含了函数被调用时传入的所有参数。作用域范围：GEC：提供了最外层的全局作用域。在GEC中声明的变量和函数可以在程序的任何地方被访问（除非被同名局部变量遮蔽）。FEC：为函数创建了一个独立的局部作用域。在FEC中声明的变量和函数，默认只能在该函数内部访问，外部无法直接访问。
它们如何交互？
GEC和FEC之间的交互主要通过执行栈（Call Stack）和作用域链（Scope Chain）来实现：
执行栈（Call Stack）的组织：
GEC始终位于执行栈的最底部。它是JS程序的起点和终点。当一个函数被调用时，一个新的FEC被创建并推入执行栈的顶部。当这个函数执行完毕后，它的FEC会从栈中弹出，控制权回到栈中下一个（通常是调用它的）上下文。这种LIFO（后进先出）的机制，决定了代码的执行顺序。
let globalVar = 'I am global'; // 在GEC中
function outer() { // outer()的FEClet 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。
作用域链（Scope Chain）的构建：
每个执行上下文的词法环境都有一个
Outer Environment Reference
，指向它的父级词法环境。GEC的
Outer Environment Reference
通常为
null
，因为它没有外部作用域。FEC的
Outer Environment Reference
指向它被定义时所在的作用域的词法环境。通过这些引用，JavaScript引擎在查找变量时，会沿着这条链条一层一层地向外查找，直到找到变量或到达GEC。这就是作用域链，它决定了变量的可访问性。这种机制使得内层函数可以访问外层函数甚至全局作用域的变量，但外层函数无法直接访问内层函数的局部变量。
这种分层且相互关联的上下文机制，是JavaScript灵活而强大的基础。它允许我们组织模块化的代码，同时又能在需要时进行跨作用域的数据共享，比如通过闭包实现私有变量和模块模式。理解这些交互，是掌握JS高级特性和避免常见陷阱的关键。
以上就是什么是JS的运行上下文？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1518392.html
微信扫一扫 
支付宝扫一扫 
