执行上下文是JS引擎为运行代码创建的内部环境，包含变量环境、词法环境和this绑定；分全局、函数、eval三类，依调用栈管理，经历创建（含提升与TDZ）和执行两阶段。
JavaScript 是一门单线程、解释执行（现代引擎实际是编译+优化）的动态语言，它的“如何工作”核心在于执行上下文（Execution Context）——这是 JS 引擎运行代码时创建的内部环境，决定了变量、函数、this 的可访问范围和生命周期。
执行上下文是什么？
执行上下文是 JS 引擎为每段正在执行的代码（全局代码、函数调用、eval）创建的一个抽象概念，包含三个关键部分：
- 变量环境（Variable Environment）：存放 var 声明、函数声明、let/const 的绑定（但 let/const 在初始化前处于“暂时性死区”）
- 词法环境（Lexical Environment）：存放 let/const 声明、函数内声明的函数，也负责作用域链查找
- this 绑定：当前执行上下文中的 this 值，由调用方式决定（如普通调用、方法调用、new、call/apply/bind）
执行上下文的类型与创建时机
JS 中主要有三类执行上下文：
- 全局执行上下文：脚本启动时自动创建，只有一个。this 指向全局对象（浏览器中是 window，Node.js 中是 global）
- 函数执行上下文：每次函数被调用时创建，每次调用都新建一个（支持递归和闭包）
- eval 执行上下文：极少使用，不推荐，行为复杂且有安全风险
注意：箭头函数没有自己的 this 和 arguments，它会沿作用域链向上查找外层函数的 this 和 arguments。
立即学习“Java免费学习笔记（深入）”；
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
执行上下文栈（Call Stack）
JS 引擎用栈结构管理执行上下文：后进先出（LIFO）。
- 代码开始执行 → 全局上下文入栈
- 调用函数 → 新函数上下文入栈（栈顶）
- 函数返回或执行完毕 → 当前上下文出栈
- 栈空 → 程序结束
例如：foo() { bar(); } 调用时，栈依次为：[全局] → [全局, foo] → [全局, foo, bar] → [全局, foo] → [全局]。
执行上下文的生命周期
每个函数上下文经历两个阶段：
- 创建阶段（Creation Phase）： • 创建变量环境，初始化 var（设为 undefined）、函数声明（赋值为函数体） • 创建词法环境，初始化 let/const（但暂不赋值，进入 TDZ） • 确定 this 值（依据调用方式） • 构建作用域链（指向外层词法环境）
- 执行阶段（Execution Phase）： • 逐行执行代码，为变量赋值（包括 let/const 初始化） • 执行函数调用、运算、控制流等
这就是为什么你可以“提前调用”函数声明（hoisting），但不能访问未初始化的 let 变量——它们在创建阶段已注册，只是执行阶段才激活。
理解执行上下文不是为了背概念，而是看清变量在哪能用、this 是谁、闭包怎么留存外层变量、为什么 setTimeout 中的 this 会丢失——这些常见问题，根源都在执行上下文的创建、链接与销毁过程里。
