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）类型的对象，但用途不同：
立即学习“Java免费学习笔记（深入）”；
-
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），帧名就是函数名或
<anonymous></anonymous> - 递归调用时，同一函数名会重复出现在栈中多个层级，每层都是独立的
FunctionExecutionContext -
async函数返回 Promise 后立即退出，其执行上下文被弹出；后续await恢复时，是在新的微任务执行上下文中继续（不是原上下文恢复）
典型陷阱：以为 await 会“暂停并保留当前上下文”，其实它只是让出控制权，再进来已是另一个上下文。
为什么 this 和作用域链容易混淆？
因为二者都依赖执行上下文，但来源完全不同：
-
this是执行上下文的一个独立属性（thisBinding），由调用方式决定（obj.fn()vsfn()vsnew Fn()），与词法环境无关 - 作用域链（
[[Scopes]]）是LexicalEnvironment.outer链式引用构成的只读链，完全静态，由函数定义位置决定 - 闭包捕获的是整个
LexicalEnvironment（含所有let/const绑定），不是单个变量值
这意味着：改写 this（如用 call）不影响作用域链；而用 eval 动态修改变量，可能绕过词法环境约束——但现代引擎对 eval 有严格限制。
真正难调试的，是那些跨执行上下文共享状态又没显式传参的地方，比如闭包里引用了外层 var 变量，又被循环多次覆盖——这时候得看清楚每个上下文的 VariableEnvironment 是否真的隔离。
