JavaScript执行上下文
前言:在看js垃圾回收时遇到相关问题,感觉自己对上下文对象理解的还是不够透彻(实在是太菜了)这就回来恶补。
执行上下文(Execution Context)
执行上下文是 JS 引擎为代码执行创建的运行环境,ES6 规范其由:
this 绑定
词法环境(Lexical Environment)
变量环境(Variable Environment)
三部分构成,三者在上下文的「创建阶段」初始化,「执行阶段」完成赋值与执行。
在 JavaScript 中,运行环境主要包含了全局环境和函数环境。
在 JavaScript 代码运行过程中,最先进入的是全局环境,而在函数被调用时则进入相应的函数环境。全局环境和函数环境所对应的执行上下文我们分别称为全局上下文和函数上下文。
在一个 JavaScript 文件中,经常会有多个函数被调用,也就是说在 JavaScript 代码运行过程中很可能会产生多个执行上下文,那么如何去管理这多个执行上下文呢?
执行上下文是以栈(一种 LIFO 的数据结构)的方式被存放起来的,我们称之为执行上下文栈(Execution Context Stack)。
在 JavaScript 代码开始执行时,首先进入全局环境,此时全局上下文被创建并入栈,之后当调用函数时则进入相应的函数环境,此时相应函数上下文被创建并入栈,当处于栈顶的执行上下文代码执行完毕后,则会将其出栈。
所以在执行上下文栈中,栈底永远是全局上下文,而栈顶则是当前正在执行的函数上下文。
1 | function fn2() { |
对于如上代码
1 | /* 伪代码 以数组来表示执行上下文栈 ECStack=[] */ |

执行上下文的创建阶段,还会完成 this的绑定、词法环境的创建、变量环境的创建:
词法环境(Lexical Environment)初始化
词法环境实际上在函数定义就已经确定了,只是在上下文创建阶段才会进行初始化,生成作用域链。由两个组成部分:
- 环境记录(environment record)
- 对外部环境的引用
环境记录(Environment Record)
存储当前上下文的变量 / 函数,细分两类:
- 函数上下文的环境记录:存储 let/const/ 函数声明 /class 声明,包含 arguments 对象(函数参数);
- 全局上下文的环境记录:存储 let/const/ 函数声明 /class 声明,关联全局对象(如 window);
外部环境引用(Outer Environment Reference)
指向外层函数(这里的外层指的是代码编写时的外层,不是执行上下文的上层调用栈)的词法环境(形成作用域链),全局上下文的外部引用为 null。
环境记录是存储变量和函数声明的实际位置,对外部环境的引用意味着它可以访问其外部词法环境。
变量环境(Variable Environment)初始化
变量环境结构与词法环境完全一致(环境记录 + 外部引用);
唯一差异:仅存储 var 声明的变量(含函数表达式中的 var 变量)
变量环境中,var 声明的变量会被 “提升” 并初始化为 undefined(这是 var 变量提升的根源)。
结合代码理解:
1 | let a = 20; |
这段代码的执行上下文:
1 | GlobalExectionContext = { |
注意: 只有在遇到函数 multiply 的调用时才会创建函数执行上下文。
这里的 let 和 const 定义的变量没有任何与之关联的值,但 var 定义的变量设置为 undefined。
这是因为在创建阶段,代码会被扫描并解析变量和函数声明,其中函数声明存储在环境中,而变量会被设置为 undefined(在 var 的情况下)或保持未初始化(在 let 和 const 的情况下)。
这就是为什么可以在声明之前访问 var 定义的变量(尽管是 undefined ),但如果在声明之前访问 let 和 const 定义的变量就会提示引用错误的原因,也就是所谓的变量提升
作用域链
作用域链:决定执行上下文的变量查找机制
作用域链 = 「(当前词法环境 + 当前变量环境) → (外层词法环境 + 外层变量环境) → … → 全局词法环境」
注意:作用域链的构建依据是 “词法位置”(代码书写时的嵌套关系),而非函数调用顺序(与执行上下文栈无关);
全局执行上下文的外部环境引用为 null,是作用域链的终点;
执行上下文栈管理上下文的 “执行顺序”,作用域链管理上下文的 “变量查找规则”,二者独立但配合工作。
以代码示例说明:
1 | // 全局执行上下文 |
执行 fn2 时,其作用域链为:fn2 词法环境 → fn1 词法环境 → 全局词法环境;
查找 a:fn2 环境无 → 向上到 fn1 环境无 → 全局环境找到 a=1;
查找 b:fn2 环境无 → fn1 环境找到 b=2;
查找 c:fn2 环境直接找到 c=3。
绑定 this 指向
this 的指向,是在函数被调用的时候确定的。也就是执行上下文被创建时确定的。
关于 this 的指向,其实最主要的是三种场景,分别是全局上下文中 this、函数中 this 和构造函数中 this。
全局上下文中 this
在全局上下文中,this 指代全局对象。
1 | // 在浏览器环境中,全局对象是 window 对象: |
函数中 this
函数中的 this 指向是怎样一种情况呢?
如果被调用的函数,被某一个对象所拥有,那么其内部的 this 指向该对象;如果该函数被独立调用,那么其内部的 this 指向 window(严格模式下指向undefined)。
1 | var a = 1; |
还有一种比较特殊的情况
1 | var o = { |
this永远指向的是最后调用它的对象,也就是看它执行的时候是谁调用的,上例中虽然函数fn是被对象b所引用,但是在将fn赋值给变量j的时候并没有执行所以最终指向的是window
构造函数中 this
要清楚构造函数中 this 的指向,则必须先了解通过 new 操作符调用构造函数时所经历的阶段。
通过 new 操作符调用构造函数时所经历的阶段如下:
- 创建一个新对象;
- 将构造函数的 this 指向这个新对象;
- 执行构造函数内部代码;
- 返回这个新对象。
所以从上述流程可知,对于构造函数来说,其内部 this 指向新创建的对象实例。
1 | function Person(name, age) { |
箭头函数的 this
箭头函数的 this 是基于词法作用域链查找的,箭头函数的this等于外层上下文创建时绑定的this
相当于箭头函数的this是静态的,绑定后不会因为函数的调用方式或者 call/apply/bind 修改
代码示例:
1 | // 全局上下文 G(this=window) |
示例2:
1 | globalThis.a = 100; |
其他
块级作用域和执行上下文的关系
块级作用域({} 包裹的代码块,如 if/for/直接 {})是词法环境的 “子环境”,依附于当前执行上下文(全局 / 函数)存在,不会创建独立的执行上下文;块级作用域仅扩展执行上下文内词法环境的存储与查找规则。
以代码示例说明:
1 | // 全局执行上下文(无独立块级执行上下文): |