17370845950

JavaScript执行上下文是引擎实际创建的有生命周期的对象，执行栈是真实LIFO内存机制；创建时机仅三种：全局代码加载、函数调用、eval执行；VariableEnvironment处理var/函数声明，LexicalEnvironment处理let/const/class；两者outer引用构成闭包基础；async/await切换上下文而非暂停；this与作用域链来源不同，前者由调用方式决定，后者由定义位置静态确定。

JavaScript 执行上下文不是“运行时环境”的抽象概念，而是引擎实际创建的、有明确生命周期的对象；执行栈也不是虚拟结构，而是真实存在的 LIFO（后进先出）内存管理机制。理解它，关键在于看清楚 GlobalExecutionContext、FunctionExecutionContext 怎么被压入/弹出，以及它们内部的 VariableEnvironment 和 LexicalEnvironment 如何协作。

执行上下文创建的三个确切时机

只有这三种情况会触发新执行上下文生成，其他都是误解：

• 全局代码首次加载时，引擎隐式创建一个 GlobalExecutionContext
• 每次调用函数（包括箭头函数、async 函数、IIFE），都会新建一个 FunctionExecutionContext
• eval() 执行非严格模式字符串代码时，会创建 EvalExecutionContext（已不推荐使用）

注意：setTimeout、Promise.then、事件回调等异步入口，本质仍是函数调用，所以也创建新的函数执行上下文——不是“延续旧上下文”，而是全新实例。

ExecutionContext 内部的两个环境对象区别

VariableEnvironment 和 LexicalEnvironment 都是词法环境（LexicalEnvironment）类型的对象，但用途不同：

• VariableEnvironment 专用于 var 声明和函数声明的绑定（含变量提升逻辑），在执行阶段才初始化值
• LexicalEnvironment 用于 let、const、class、import 绑定，且在进入执行上下文阶段就完成初始化（所以存在暂时性死区）
• 两者都包含 outer 引用，指向外层词法环境——这就是闭包的物理基础

例如：

function foo() {
  var a = 1;
  let b = 2;
  console.log(a, b); // 此处执行上下文中：
                     // VariableEnvironment: { a: undefined → 1 }
                     // LexicalEnvironment: { b: 2 }（b 不会是 undefined）
}

执行栈变化可被直接观测

虽然 V8 不暴露栈结构 API，但通过 console.trace() 或断点调试器的 Call Stack 面板，能清晰看到上下文的压入/弹出顺序：

• 每个函数调用对应栈中一个帧（frame），帧名就是函数名或
• 递归调用时，同一函数名会重复出现在栈中多个层级，每层都是独立的 FunctionExecutionContext
• async 函数返回 Promise 后立即退出，其执行上下文被弹出；后续 await 恢复时，是在新的微任务执行上下文中继续（不是原上下文恢复）

典型陷阱：以为 await 会“暂停并保留当前上下文”，其实它只是让出控制权，再进来已是另一个上下文。

为什么 this 和作用域链容易混淆？

因为二者都依赖执行上下文，但来源完全不同：

• this 是执行上下文的一个独立属性（thisBinding），由调用方式决定（obj.fn() vs fn() vs new Fn()），与词法环境无关
• 作用域链（[[Scopes]]）是 LexicalEnvironment.outer 链式引用构成的只读链，完全静态，由函数定义位置决定
• 闭包捕获的是整个 LexicalEnvironment（含所有 let/const 绑定），不是单个变量值

这意味着：改写 this（如用 call）不影响作用域链；而用 eval 动态修改变量，可能绕过词法环境约束——但现代引擎对 eval 有严格限制。

真正难调试的，是那些跨执行上下文共享状态又没显式传参的地方，比如闭包里引用了外层 var 变量，又被循环多次覆盖——这时候得看清楚每个上下文的 Variab