执行上下文是什么？怎么影响代码运行？

JavaScript执行上下文是代码运行背后的“隐形指挥官”，它作为环境容器，精准掌控着变量声明、函数访问、this绑定及作用域链的形成逻辑；通过全局、函数、eval三类上下文的栈式管理，配合创建与执行两个严格分离的阶段，JS得以实现单线程下的嵌套调用、块级作用域、变量提升与暂时性死区等核心机制——读懂它，就真正掌握了JavaScript运行时行为的底层密码。

JavaScript 中的执行上下文（Execution Context）是代码运行时的“环境容器”，它决定了变量、函数、this 的可访问范围和取值。理解它，就等于看清了 JS 代码“每一步到底在哪个环境中执行”。

执行上下文的三种类型

JS 引擎在运行代码前，会为不同场景创建对应类型的执行上下文：

• 全局执行上下文：脚本启动时自动创建，只有一个。其中 this 指向全局对象（浏览器中是 window，Node.js 中是 global）。
• 函数执行上下文：每次调用函数时创建，每次调用都生成一个**全新**的上下文，彼此隔离。this 的值由调用方式决定（如普通调用、call/apply、箭头函数等）。
• eval 执行上下文：极少使用，不推荐，此处略过。

每个执行上下文内部包含什么？

它不是抽象概念，而是有明确结构的运行时对象，主要含三部分：

• 词法环境（Lexical Environment）：存储 let/const 声明的变量、函数声明，以及对外层环境的引用（outer）。支持块级作用域（如 if、for 内的 let）。
• 变量环境（Variable Environment）：早期用于 var 声明的提升（hoisting），现在与词法环境高度重合，但语义上仍区分——var 在变量环境里初始化为 undefined，而 let/const 在词法环境中处于“暂时性死区”（TDZ）。
• this 绑定：在上下文创建阶段就确定，不依赖后续代码，比如箭头函数的 this 直接继承外层上下文的 this。

执行上下文栈（ECStack）如何控制运行顺序？

JS 是单线程的，靠栈结构管理多个上下文的生命周期。它像一个“执行日志本”，只允许在栈顶上下文运行代码：

• 全局代码开始执行 → 全局上下文入栈（栈底）
• 遇到函数调用 → 新的函数上下文被创建并压入栈顶
• 函数执行完毕 → 栈顶上下文弹出，控制权交还给下一层（可能是另一个函数，也可能是全局）
• 整个过程形成“先进后出”的嵌套执行流，自然体现函数调用链和作用域链的查找路径

例如：foo() 调用 bar()，bar() 再调用 baz()，则栈从底到顶为：[全局] → [foo] → [bar] → [baz]；baz 返回后，bar 继续执行剩余代码。

执行上下文的两个阶段：创建与执行

每个上下文并非一创建就直接运行，而是严格分两步：

• 创建阶段：确定 this、建立词法环境与变量环境、处理声明（var 提升为 undefined，let/const 进入 TDZ，函数声明被完整提升）
• 执行阶段：逐行执行代码，为变量赋值、执行函数调用、触发闭包捕获等

这个分离让 JS 能在真正执行前就准备好所有作用域和绑定关系，是理解 hoisting 和 TDZ 的关键。

到这里，我们也就讲完了《执行上下文是什么？怎么影响代码运行？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！