执行上下文不是作用域，但作用域链由其 LexicalEnvironment 的 outer 指针链式构成；它分全局、函数、eval 三种，创建于代码执行或函数调用时，不因块级语法产生；作用域链在函数定义时确定，闭包通过 [[Environment]] 持久引用外层词法环境。
执行上下文不是 作用域，但作用域链由它生成
执行上下文（ExecutionContext）是 JS 引擎在运行代码时创建的内部对象，用于管理变量、函数声明、this 绑定和控制流。它不等于作用域（Scope），但每个执行上下文都包含一个 [[Environment]] 内部槽位，这个槽位指向当前的作用域链起点——也就是该上下文「诞生时」所处的词法环境。
全局、函数、eval 三种执行上下文的创建时机不同
JS 引擎只在特定时刻创建执行上下文：
- 全局代码开始执行时，创建唯一的
GlobalExecutionContext - 每次调用函数时，创建一个新的
FunctionExecutionContext（即使递归调用，每次也新建） -
eval()执行字符串代码时，可能创建EvalExecutionContext（严格模式下不继承外层变量）
注意：if、for、{} 块不会创建新的执行上下文（ES6 的 let/const 块级绑定属于词法环境，不是执行上下文）。
作用域链是执行上下文的 LexicalEnvironment 链式查找路径
每个执行上下文的 LexicalEnvironment 字段是一个记录结构，包含：EnvironmentRecord（存当前作用域的变量）和 outer（指向外层词法环境）。作用域链就是从当前 LexicalEnvironment 开始，沿着 outer 指针逐级向上直到全局环境的链表。
立即学习“Java 免费学习笔记（深入）”；
关键点：
- 作用域链在函数定义时就确定（基于词法位置），不是调用时决定
- 闭包能访问外层变量，正是因为其函数对象的
[[Environment]]持有对外层LexicalEnvironment的引用 -
with和catch语句会临时修改当前执行上下文的LexicalEnvironment，导致作用域链变长（不推荐使用）
常见误区：this 不在作用域链里，也不参与变量查找
this 是执行上下文的一个独立属性（ThisBinding），它的值取决于调用方式（如 obj.fn() vs fn()），与作用域链完全无关。变量查找只走 LexicalEnvironment 链，永远不查 this。
下面这个例子容易让人混淆：
function foo() { console.log(a); // ReferenceError: a is not defined console.log(this.a); // undefined（非严格模式下 this 指向 global）} foo();第一行报错是因为变量 a 不在任何作用域链上；第二行不报错是因为 this.a 是属性访问，不是标识符解析。
执行上下文的生命周期很短，但它的 LexicalEnvironment 可能被闭包长期持有——这才是理解变量“意外存活”的关键。很多人调试时只看调用 栈，却忘了每个栈帧背后还挂着一条看不见的词法环境链。
