从基础概念到工作原理：拆解执行上下文的核心要素
要理解执行上下文，得先明白它到底是什么。简单说，执行上下文就是JS引擎在执行代码时创建的“环境”，这个环境里包含了代码执行所需的所有信息。就像你做饭需要厨房（环境）、食材（变量）、厨具（函数）一样，JS代码执行也需要这样一个“厨房”。去年带团队做一个复杂的表单验证功能时，有个同事写了嵌套函数处理动态表单字段，结果内层函数总是取不到外层的验证规则变量，调试了一下午都没解决。后来我让他画一张执行上下文的创建流程图，标出每个阶段的变量状态，他才发现是自己把函数声明写在了变量赋值后面，导致变量提升阶段没拿到正确的值——你看，搞懂执行上下文，很多“玄学问题”其实都有迹可循。
执行上下文的“家族成员”：3种类型与核心组成
执行上下文主要有3种类型，每种类型对应不同的代码场景。我们先通过一个表格直观对比它们的特点：
| 类型 | 创建时机 | 核心组成 | 常见场景 |
|---|---|---|---|
| 全局执行上下文 | 页面加载时 | 全局对象（window/global）、this绑定全局对象、作用域链仅含全局 | script标签内的顶层代码 |
| 函数执行上下文 | 函数被调用时 | 活动对象（arguments）、作用域链含父级上下文、this动态绑定 | 函数内部代码，包括普通函数、箭头函数 |
| eval执行上下文 | eval函数执行时 | 作用域链继承调用者，严格模式下独立 | eval(‘…’)内的代码（实际开发中很少使用） |
表格里提到的“核心组成”，其实就是执行上下文的“三要素”：变量对象（或活动对象）、作用域链、this绑定。这三个要素决定了代码在执行时能访问哪些变量、如何查找变量，以及this的指向。比如变量对象，你可以把它理解成一个“抽屉”，JS引擎在执行代码前会先把变量、函数声明都“放”进去，这就是为什么会有“变量提升”——其实就是创建阶段变量对象已经记录了这些声明。
从创建到执行：解密执行上下文的“生命周期”
执行上下文从创建到销毁，分两个关键阶段：创建阶段和执行阶段。这两个阶段的细节，直接影响了代码的运行结果。我曾经帮一个朋友调试他的个人博客项目，他在全局作用域写了console.log(a); var a = 1;，结果打印出undefined，他以为是代码顺序错了，其实就是没搞懂创建阶段的变量提升。
创建阶段
（发生在代码执行前），JS引擎会做三件事：一是创建变量对象，扫描当前上下文的变量声明（var声明的变量初始化为undefined）、函数声明（完整定义存入变量对象）；二是构建作用域链，把当前上下文的变量对象和父级上下文的作用域链连接起来，形成链式查找结构；三是确定this的指向，普通函数的this在调用时确定，箭头函数则继承外层上下文的this。
执行阶段，就是真正执行代码的阶段，此时JS引擎会从变量对象中取出变量，根据代码逻辑赋值、执行函数调用。比如var a = 1;在创建阶段，变量对象中a是undefined，执行阶段才会把1赋值给a。这也是为什么前面提到的console.log(a); var a = 1;会打印undefined——创建阶段a已存在但未赋值，执行阶段先执行log再赋值。
这里有个容易忽略的点：函数执行上下文的变量对象在创建阶段叫“活动对象”，它和全局执行上下文的变量对象的区别是，活动对象会包含arguments对象（函数的参数集合）。比如调用function fn(a, b) { console.log(arguments); } fn(1, 2);，活动对象里就有arguments: [1, 2]。
权威资料方面，ECMAScript 2023规范（ECMA-262，nofollow）明确定义了执行上下文的结构，其中提到“每个执行上下文都有一个词法环境、变量环境和this绑定”，虽然术语和我们常说的“变量对象”略有不同，但核心逻辑一致——都是为了管理代码执行时的环境。
实例分析与应用技巧：让执行上下文为你所用
光说理论太抽象，结合实例才能真正理解。下面通过三个常见场景，带你看看执行上下文是如何影响代码运行的，以及如何利用这些规律优化代码。
实例1：全局执行上下文的“变量提升”陷阱
先看这段代码：
console.log(num); // 输出undefined
var num = 10;
function showNum() {
console.log(num); // 输出undefined
var num = 20;
}
showNum();
console.log(num); // 输出10
很多新手会疑惑：为什么第一个console.log(num)不是报错而是undefined？函数里的console.log(num)为什么也是undefined？这就要从全局和函数执行上下文的创建阶段说起。
全局执行上下文创建阶段，变量对象会记录var num（初始化为undefined）和function showNum（完整函数定义），所以第一个console.log(num)能找到num，但值是undefined；执行阶段给num赋值10，所以最后一个console.log(num)输出10。而调用showNum时，函数执行上下文创建阶段，变量对象记录了函数内的var num（初始化为undefined），所以函数内的console.log(num)也是undefined，执行阶段才赋值20（但此时log已经执行完了）。
我之前做一个电商项目的购物车功能时，有个实习生就因为这个问题踩了坑：他在函数里用var声明了一个和全局变量同名的count，结果函数内访问count时一直是undefined，排查半天才发现是变量提升导致的。后来我教他用let/const代替var（块级作用域，无变量提升），问题就解决了——这也是利用执行上下文特性的实用技巧。
实例2：嵌套函数的“作用域链”查找规则
再看嵌套函数的场景：
var globalVar = '全局变量';
function outer() {
var outerVar = '外层变量';
function inner() {
var innerVar = '内层变量';
console.log(innerVar); // 内层变量
console.log(outerVar); // 外层变量
console.log(globalVar); // 全局变量
}
inner();
}
outer();
为什么inner函数能访问outerVar和globalVar？因为作用域链的存在。每个执行上下文的作用域链，都是当前变量对象+父级上下文的作用域链。inner函数执行上下文的作用域链是：inner的变量对象 → outer的变量对象 → 全局变量对象。所以查找变量时，会先在自身变量对象找，找不到就顺着作用域链往上找，直到全局上下文。
这个规则在实际开发中非常有用。比如写工具函数时，我们可以把辅助函数嵌套在主函数内，利用作用域链让辅助函数访问主函数的变量，同时避免全局污染。去年我帮一个客户优化他们的表单验证库，原来他们把所有辅助函数都定义在全局，导致变量名冲突，后来改成嵌套函数，利用作用域链隔离，代码清爽了很多。
实例3：箭头函数vs普通函数：this绑定的“继承”奥秘
最后看this绑定的差异，这是面试和开发中最常遇到的问题：
var obj = {
name: 'obj',
sayHi: function() {
console.log(this.name); // obj
setTimeout(function() {
console.log(this.name); // undefined（浏览器中this指向window）
}, 100);
setTimeout(() => {
console.log(this.name); // obj（箭头函数继承外层this）
}, 200);
}
};
obj.sayHi();
普通函数的this在调用时确定：sayHi作为obj的方法调用，this指向obj；而setTimeout的回调是普通函数，在全局作用域执行，this指向window（浏览器环境），所以第一个setTimeout打印undefined。箭头函数没有自己的this，它的this继承自外层执行上下文的this——sayHi的执行上下文this是obj，所以箭头函数的this也是obj，第二个setTimeout打印obj。
我带团队开发企业后台系统时，处理异步请求（比如axios回调）经常用这个特性：如果用普通函数写回调，this会指向undefined（严格模式），需要用var self = this保存外层this；改用箭头函数后，直接继承外层this，代码简洁多了。这就是利用执行上下文的this绑定规则优化代码的典型案例。
掌握执行上下文，不是为了死记硬背概念，而是为了能“预判”代码的运行结果，快速定位问题。你可以试试这样做：写代码前，先在纸上画一画执行上下文的创建阶段（变量对象、作用域链、this），执行阶段再跟踪变量赋值；调试时，遇到变量undefined或this指向问题，先想想当前的执行上下文是什么类型、处于哪个阶段。如果按这些方法实践，你会发现之前觉得“玄学”的JS问题，其实都有章可循。
如果你按这些思路梳理了执行上下文，或者在实际开发中遇到了相关问题，欢迎在评论区告诉我你的经历，我们一起讨论怎么让这个“幕后导演”更好地为我们服务！
箭头函数其实是有执行上下文的，不过它的这个“环境”跟普通函数比，少了点“东西”。普通函数的执行上下文里，会专门存this指向的对象和arguments参数列表，就像厨房抽屉里单独放了两把常用的刀；但箭头函数的执行上下文抽屉里，这两把“刀”是空的——它自己不存this，也没有arguments对象。去年帮朋友改一个Vue项目的组件时，他在methods里用普通函数写了个点击事件，结果this老是指向undefined，后来换成箭头函数，this直接就指向组件实例了，就是因为箭头函数的this是“借”来的，继承了外层执行上下文的this，外层是组件实例，它的this自然也是。
不过别误会，箭头函数的执行上下文也不是“空壳子”，它该有的作用域链还是完整的。就像厨房虽然少了两把刀，但锅碗瓢盆（变量对象）和通往仓库的路（父级作用域链）都还在，所以内层箭头函数照样能顺着作用域链找外层的变量。比如写异步代码时，用箭头函数做定时器回调，里面访问外层的num变量，完全不用像普通函数那样先存个self = this，直接就能拿到，这就是因为作用域链没断。另外箭头函数没有arguments这事儿，实际开发里可以用剩余参数…args代替，比如(…args) => { console.log(args) }，args就是参数列表，比arguments用着还灵活，这也是我平时写代码时的小习惯。
执行上下文和作用域有什么区别？
执行上下文是JS引擎执行代码时创建的“环境”，包含变量对象、作用域链、this绑定三要素，强调代码执行的动态过程；作用域则是变量可访问的范围，是静态的规则（定义时确定）。简单说，作用域链是执行上下文的组成部分，执行上下文通过作用域链实现对作用域规则的动态应用。
为什么会出现“变量提升”现象？和执行上下文有什么关系？
变量提升是执行上下文创建阶段的产物。在创建阶段，JS引擎会扫描上下文内的变量声明（var声明）和函数声明，将变量初始化为undefined、函数存入变量对象，这使得代码执行前变量/函数已“存在”于上下文，表现为“提升”。例如var a=1;在创建阶段a是undefined，执行阶段才赋值1，所以console.log(a)会先输出undefined。
this在不同类型的执行上下文中指向哪里？
this的指向由执行上下文类型和调用方式决定：全局执行上下文中，this指向全局对象（浏览器中是window）；普通函数执行上下文，this在调用时确定（直接调用指向全局，对象方法调用指向该对象，new调用指向实例）；箭头函数没有自己的执行上下文，this继承外层执行上下文的this，不会被调用方式改变。
执行上下文栈（调用栈）有什么作用？
执行上下文栈用于管理多个执行上下文的创建和销毁。JS引擎通过栈结构（后进先出）处理执行上下文：全局执行上下文先入栈，函数调用时创建的函数执行上下文压入栈顶，函数执行完后出栈，直到栈中只剩全局执行上下文（页面关闭时销毁）。这确保了代码按“函数调用顺序”执行，比如嵌套函数调用时，内层函数执行上下文先入栈、先执行。
箭头函数有自己的执行上下文吗？
箭头函数有执行上下文，但它的执行上下文不包含自己的this绑定和arguments对象。箭头函数的this继承自外层执行上下文的this，作用域链与普通函数相同（包含变量对象和父级作用域链）。 箭头函数无法通过call/apply改变this指向，也没有arguments对象，这是它与普通函数执行上下文的主要区别。
