这个系列文章，已经写了一少半了，现在终于到了动态执行阶段了。
我们首先需要梳理一下知识，这部分内容，相对独立，但是都算是比较重要的知识点。
预编译的说法为什么不建议使用
在我们平时看文章，看资料，甚至是看一些比较权威的文档时，预编译 这个术语非常常见。但是，在js中，预编译 是个伪术语，是一些教材教程在以前的js教学中，为了解释变量提升等一些问题，生造出来的一个词语，后来，只要是运行期以前的 甚至是在和运行期交织发生的一些动作流程，统统装进了 预编译 这个大口袋里。大部分人，也就不求甚解的接受并使用了这个说法。但是，这是一个不规范且容易引发歧义的词汇。在传统编译语言中，预处理、编译与执行通常有明确的时间边界；在现代 JavaScript 环境，这些阶段高度交织。规范（ECMAScript (ECMA-262)）并不使用“预编译”一词，而是通过“执行上下文的创建阶段（creation / declaration instantiation）”来描述声明的注册与初始化。实际引擎（例如 V8）则采用惰性解析与按需编译：先做必要的解析与作用域分析，再由解释器生成字节码（如 Ignition）或在运行时将热点编译为机器码（由优化器完成）。
对于js，可以分为如下四个宏观的阶段：
词法分析：把源代码分成记号（tokens）。
语法分析（Parsing）：构建抽象语法树（AST），确定静态作用域结构。
执行上下文创建阶段（Creation / Declaration Instantiation）：为全局或每次函数调用登记标识符（函数声明整体被绑定；var 注册并初始化为 undefined；let/const 注册但处于 TDZ）。这一步决定了变量可见性和提升行为，但不等于把所有代码预先编译成机器码。
执行阶段：逐条执行语句；遇到函数调用重复执行上一 步。现代引擎会在此阶段对运行行为收集反馈，并按需触发优化编译。
全局创建阶段和函数创建阶段的区别
无论是全局还是函数，在代码真正执行前都会经历“创建阶段”（进行变量和函数声明的提升），但两者有本质区别：
作用域范围：
全局阶段：影响整个程序，声明的变量和函数最终挂载到全局环境（浏览器中为 window）。
函数阶段：每调用一次函数，生成一个完全独立的执行上下文，仅对函数体内部有效，互不干扰。
变量遮蔽(shadowing)：
四个宏观的阶段
JavaScript 代码的完整生命周期分为以下四个阶段：
var 变量注册并初始化为 undefined；将 let/const 注册，但置于“暂时性死区（TDZ）”。null。this 绑定。arguments 对象。new 调用等）计算并保存当前函数的 this 值。静态结构AST和动态运行执行阶段的关系
这是理解 JS 闭包和作用域链最核心的关键。
在语法分析结束后，AST 已经固化了代码的静态结构（Lexical Scope）。作用域的层级、变量的引用关系在这个阶段已经完全确定。
具体的词法环境实例（Lexical Environment）是在代码执行阶段动态创建的。
AST 阶段就像是建筑设计图，明确了房间的布局（作用域）和走廊的连接关系（静态作用域链）。而运行时相当于实际建造，根据设计图动态分配水泥建材（内存），并让住户（变量值）真正住进去。
闭包形成的动态实例：
JavaScript
function outer() {
var a = 10;
function inner() {
console.log(a); // 引用了 outer 的变量 a
}
return inner;
}
var closureFunc = outer();
closureFunc();
语法分析阶段：AST 记录了标识符 a 的引用关系，随后的作用域分析（Scope Analysis）会基于 AST 建立变量解析的静态链接。
执行 outer() 时：创建新的执行上下文和词法环境（包含 a）。inner 函数被创建时，捕获当前词法环境并存入其 [[Environment]]。
执行 closureFunc() 时：inner 执行，虽然 outer 的上下文已销毁，但 inner 通过自身的 [[Environment]] 依然保留着对 outer 词法环境的物理引用，真正的闭包在此刻发挥作用。
词法环境和作用域链
这两个概念非常容易混淆：
{}）时都会实例化对应的词法环境。Outer Reference（外部引用）串联而成的查找路径。如果把作用域链比作一面“墙”，那么每一个词法环境就是砌成这面墙的“砖块”。词法环境负责“存储变量”，作用域链负责提供“查找路径”。
这里需要特别注意，前面 尤其是解析篇中 我们反复强调了 蓝图 这个说法，在ast生成以后，作用域已经形成，这里要注意，是结构的形成，我们可以知道，某个变量可以到哪里寻找，但是，这只是蓝图 ，并不是实例的形成。 真正的可操作的作用域/链，是在执行阶段动态创建的。
执行上下文的模型
一、 执行上下文的抽象模型
在 ECMAScript 规范中，一个执行上下文（Execution Context）记录可以抽象为如下结构：
JavaScript
Execution Context Record = {
LexicalEnvironment: {
EnvironmentRecord: { ... }, // 当前词法环境中的绑定 (let/const/function/class)
Outer: <reference to outer env> // 外部环境引用
},
VariableEnvironment: {
EnvironmentRecord: { ... }, // 专门存储 var 声明的绑定
Outer: <reference to outer env>
},
ThisBinding: <the value of this>, // 当前上下文的 this 值
PrivateEnvironment: <optional record> // 用于类的私有字段（#private）
}
环境记录的类型与功能：
DeclarativeEnvironmentRecord（声明性环境记录）： 用于存放命名绑定（let、const、function 等），并跟踪每个绑定的内部状态（如是否已初始化、是否可变）。let/const 的 TDZ（暂时性死区）正是通过在绑定创建后、初始化前，将该绑定底层标记为“未初始化（uninitialized）”来实现的。
ObjectEnvironmentRecord（对象环境记录）： 将一个普通对象包装成环境记录。典型场景是全局环境（将 globalThis 作为绑定载体）或被废弃的 with 语句。它的查找是通过直接的对象属性访问来实现的。
FunctionEnvironmentRecord（函数环境记录）： 声明性环境记录的特化版，专职负责管理函数的参数、arguments 对象，以及处理 this、super 的绑定状态。
二、 词法环境和变量环境的区分
在函数初始执行时，LexicalEnvironment 和 VariableEnvironment 通常指向同一个环境记录实例。但规范特意将它们物理分离，是为了在“绑定创建阶段”区分不同声明的处理策略：
历史和兼容： 在 ES5 及之前，声明以函数作用域为准（var）。ES6 引入了块级作用域（let/const）。规范通过 VariableEnvironment 负责 var，LexicalEnvironment 负责块级声明，完美实现了旧行为与新特性的并存。
var 的处理（变量环境）： var 声明会在 VariableEnvironment 上被创建并立刻初始化为 undefined。这就是为什么在声明前读取 var 变量会得到 undefined（即“变量提升”）。
let/const 的处理（词法环境）： 它们在 LexicalEnvironment 上被创建，但并不初始化。在实际执行到声明语句之前，访问这些绑定会触发 TDZ，抛出 ReferenceError。
三、 上下文完整实例
我们通过一段经典代码，观察环境及闭包的情况：
JavaScript
console.log(foo);
var foo = 10;
function outer() {
let a = 1;
function inner() {
console.log(a);
}
return inner;
}
const closureFunc = outer();
closureFunc();
1. 全局创建阶段
foo 注册到变量环境，初始为 undefined。outer 函数对象创建，其内部槽 [[Environment]]（闭包的环境指针）指向当前的全局词法环境。
注意：ES6 后的全局环境是复合的，包含一个“全局声明性环境”（存 let/const）和一个“全局对象环境”（存 var 和全局函数，映射到 globalThis）。在 ES Modules 模式下，顶层绑定则由专属的 Module Environment Record 接管，不再使用 globalThis。
2. 执行全局代码
console.log(foo) 输出 undefined，因为 foo 的 var 绑定已在创建阶段完成初始化。随后 foo 赋值为 10。
3. 调用 outer() 并进入其创建阶段
注册局部变量 a（处于 TDZ）。创建 inner 函数对象，将其 [[Environment]] 指向 outer 的词法环境。随后执行赋值 a = 1（解除 TDZ），并返回 inner 函数。
注意：此时如果在 a = 1 之前尝试读取 a，会立刻触发 TDZ 报错。
4. 调用 closureFunc()（即 inner）
创建 inner 的执行上下文。在其自身的词法环境中找不到 a，顺着 [[Environment]] 构成的作用域链，向外查找到 outer 环境中的 a，输出 1。
闭包的真实情况：
inner 的 [[Environment]] 保存的是对 outer 词法环境的引用，而不是当时绑定值的快照！闭包捕获的是“绑定本身”。因此，如果 outer 后续修改了 a 的值，inner 再次执行时读取到的必然是最新的修改值。这也解释了为什么在 for 循环中使用 var 创建闭包，所有闭包会共享同一个循环变量绑定（最终输出相同的值），而使用 let 则会为每次迭代创建独立的绑定环境。
补充内容：
This 绑定（ThisBinding）
this 的值并非由执行上下文自动决定为某个固定值，而是严格由调用方式在运行时动态决定：
fn())：非严格模式指向全局对象，严格模式为 undefined。obj.method())：指向调用者对象（基值 obj）。call / apply / bind)：由传入的第一个参数决定。new Fn())：指向内部新创建的实例对象。this，它会穿透当前上下文，从创建时的外层词法环境中继承 this（Lexical This）。因此箭头函数无法被 new，也不能被 bind 改变指向。私有环境（PrivateEnvironment）
这是规范专为支持类私有成员（如 #x）引入的机制。在类定义阶段，私有标识符会被登记到私有环境中。访问时，引擎只在当前类的私有环境中查找对应绑定。对外表现为：无法通过 obj['#x'] 访问，也不会出现在 Object.keys 的枚举中。
优化与性能
现代 JavaScript 引擎对闭包和作用域链有极强的优化（例如 V8 的逃逸分析），闭包本身并不总是天然低效。但需要注意，如果无意中让闭包捕获了大型外部数据结构（或庞大的 DOM 节点），会导致这些环境记录的生命周期被强行延长，阻碍垃圾回收，从而造成内存泄漏。因为闭包会让被捕获的外部绑定“活得更久”，所以在高性能场景需谨慎管理引用。
重要总结一
前面我们讲了，js中，预编译是个伪术语，尽量不要使用。 那么，除了使用规范中的术语，我们在工程实现中，可以使用 编译期 这个术语。
一段源码要想跑起来，只要经历了“词法分析 -> 语法分析 -> 生成 AST -> 生成某种中间代码（如字节码）”的过程，这个过程在计算机科学中就被标准的定义为“编译（Compilation）”。 既然 V8 引擎确确实实做了这些事情，那把它称为“编译期”是名正言顺的。
但是需要注意：一是 传统语言的“编译期”和“运行期”可能相隔很长的时间（开发者在电脑上编译好，发给用户运行）。而 JS 的“编译期”和“运行期”是首尾相连、紧密贴合的。引擎通常在接收到代码后，立刻进行编译，随后立刻交由解释器执行。二是 在现代 V8 引擎中，纯粹的“编译期”通常指 Ignition 将 AST 转换为字节码的过程。但在“运行期”中，TurboFan 编译器依然会在后台将热点字节码再次编译成机器码。所以 JS 的“编译”行为基本上是贯穿了运行的始终。
重要总结二
在前面我们讲了上下文 讲了词法环境 环境记录 等等概念，很多朋友肯定会有疑问：
这些所谓的上下文、环境记录，到底是完全虚构出来的抽象概念，还是在物理内存中真实存在的结构？
关于这个问题，或者说 关于类似的问题，我们需要从两个方面来看，一是规范 二是实现，而这种思考方式，是我们从开篇就一直贯彻使用的。
规范
前面列出的包含了 LexicalEnvironment、Outer 引用的对象结构，还有环境记录，还有之前的let的for循环等等等等，实际上是 ECMAScript 规范定义的一种抽象机制（Abstract Mechanism）。 规范委员会（TC39）只负责制定语义上的“规则条文”：他们规定了代码跑起来后，变量查找必须遵循什么顺序、闭包必须保留什么数据，但规范绝不干涉引擎在内存中必须使用何种底层数据结构来实现这些规则。
实现
V8 引擎作为极致追求性能的“实现者”，通常不会在内存里一对一地去“照搬”或者 new 出规范中描述的那种深层次嵌套的庞大对象。相反，它会使用栈帧（Stack Frame）、寄存器（Register）、堆上对象（Heap Object）等极其底层的机制，来“实现/模拟/达到语义要求”并提供相同的行为表现。
下面，我们从规范层和实现层来学习一下这几个概念
StandardFrame、JavaScriptFrame 等）。这块内存里压入了：返回地址、参数、接收者（this）、以及分配给局部变量的寄存器槽位。函数一 return，栈帧出栈，其物理状态瞬间回收。let/const）与老旧的函数级作用域（var）。Environment 的统一 C++ 对象。相反，V8 会对绑定进行极其精明的按需分流：
Context 结构中。var 往往直接映射为全局对象的属性（Property Cell），而全局的 let/const 则属于声明式记录；且 var 没有 TDZ 标记。引擎通过不同的底层操作指令来严格区分这两种语义。这是反差最大的一个概念。在规范里它像个哈希表，但在 V8 底层，它被分化成了三种截然不同的物理形态：
r0）。执行时没有运行时的字符串查找，只有纯粹的内存/寄存器读写指令。Context / Slot 结构。FixedArray（固定数组）或包含 Cell 引用的结构。闭包变量以固定的槽位索引（Slot Index）存储。访问时通过“基地址 + 偏移量”极速拿取，而非哈希查找。new 出这个堆数组。通常在运行时或编译阶段，借助强大的逃逸分析（Escape Analysis），引擎会尽量延迟甚至消除这种堆分配，只有在无可避免（真正创建闭包引用）时才在堆上开辟空间。window）的属性可以被动态增删，无法提前确定数组大小，引擎通常使用更通用的字典结构或 Property Cell 来存放，这在语义上最接近传统的哈希表。Context 结构中，会保留一个指向父 Context 的指针（通常位于特定的槽位中）。当当前上下文查找未命中时，引擎会沿着这些真实的物理指针，按索引继续向外层查找，从而在物理内存中串联起一条真正的作用域链（Scope Chain）。[[Environment]]JSFunction 的实例）会包含一个专属的字段（在源码中常见的命名如 context_）。这个字段保存着指向创建时词法环境（堆上的 Context 对象）的内存引用，这就是闭包能够“记住”外部环境的物理铁证。【规范层：抽象级别 - 逻辑态】
let/const 绑定已创建但未初始化，此时访问将抛出 ReferenceError。【V8层：物理表现形式与载体】
the_hole 的特殊 Tagged Value）。ReferenceError。一旦代码执行到了真实的赋值语句，真实的数据就会覆盖掉这个哨兵值，TDZ 随之在物理层面上被解除。在前面学习字节码生成的时候，我们使用了导演 场务 记录员 这个比喻，随着我们的学习深入，很有必要扩展一下我们的 片场宇宙 ，下面我们把片场宇宙的整体设定，以表格的形式固定下来，这个设定，应该足以支撑我们的后续学习了。而且 在记忆点，在准确性 等方面，也是挺合适的。 这是我的原创丫，保留版权。盗版会被追杀的。 嘿嘿嘿。。。
一、 基建与环境
| 片场比喻 | V8 底层实体 | 核心职责与表现 |
|---|---|---|
| 大老板 / 制片人 | Host Environment (宿主：Chrome/Node.js) | 掌握生杀大权。负责出资建厂，并在一切准备就绪后扣动 Execution::Call 扳机，下达全场开机指令。 |
| 独立制片厂 | Isolate | 进程内的独立工业园区。拥有专属土地和主线程。不能擅自串门，所有跨厂通信须通过宿主提供的 IPC 桥接机制（如 postMessage / embedder bridge），以保证隔离策略与安全边界。 |
| 拍摄场域 | Realm | 对应一套完整的全局内置对象体系。有助解释不同脚本/模块之间的原型链与全局隔离等高级语义（如 iframe 之间的差异）。大多数情况下，Realm（规范概念） = Context（V8 物理实现） |
| 逻辑摄影棚 | Context | 搭建在制片厂内的执行环境。提供基础道具（如当前的 window/global 实例）。同厂内可有多棚，互不串戏。 |
| 预制构件厂 | mksnapshot (快照机制) | 编译期打包好的引擎原生初始化对象与初始堆状态。开新棚时“拎包入住”。（注意：并不等同于把用户的运行时代码或业务脚本提前编译为机器码）。 |
| 清道夫 / 场地清理队 | GC (垃圾回收器) | 分两队：新生代突击队（Scavenge）用复制算法把还在用的道具完整搬到新片场，旧片场一键清空；老生代重型拆迁队用 Mark-Sweep 清理废弃垃圾，并用 Mark-Compact（标记压缩）把还在用的别墅统一挪到地块前排，消除内存碎片。 |
| 道具仓库管理员 | Object Factory | 制片厂专属库管。负责统一创建、分配所有 JS 对象、字符串、数组等道具，确保所有出库道具严格符合定妆照标准。 |
二、 剧组班底与工作人员
| 片场比喻 | V8 底层实体 | 核心职责与表现 |
|---|---|---|
| 原著编剧与审核员 | Parser & Syntax Checker | 拆解源代码并同步查错（如括号不匹配、非法语法）。剧本不合格直接打回，导演休想开工。 |
| 导演 | BytecodeGenerator (字节码生成器) | 掌控全局的大佬。拿着 AST 原稿，决定指令走向，画出最初的分镜头脚本。 |
| 场务 | BytecodeRegisterAllocator | 抠门的空间管理大师。编译期负责精打细算分配椅子（寄存器），算出“最高水位线”，打下 Frame Size 物理钢印。 |
| 记录员 / 老编辑 | BytecodeArrayBuilder | 手速如飞的记录员。自带“窥孔优化（Peephole）”职业病，听到导演喊了废话（如冗余存取）直接在脑子里抹掉。 |
| 无情的男一号 | Ignition 解释器 | 极速执行机器与 V8 默认入口。哪怕特效师临时救场，全场的最终兜底权永远在男一号手里。 |
| 海关 / 双向安检员 | JSEntry & CEntry Stub | 驻守 C++ 与 JS 边界。砸下防爆门，并在 Entry Frame 中保存返回地址与调用约定，确保 C++ 与 JS 间的调用契约被完整维护，防止异常穿透。 |
| 后期特效师 | TurboFan (优化编译器) | 激进的赌徒。只接“跑热了”的戏份（执行次数超阈值），冷剧本绝不碰。 赌定演员的定妆照（Map）绝对不变。 |
三、 核心道具与约定
| 片场比喻 | V8 底层实体 | 核心职责与表现 |
|---|---|---|
| 分镜头原稿 | AST (抽象语法树) | 导演看的分镜头原稿，上面画满了变量的作用域归属（住栈上还是住别墅）。 |
| 公共图纸 | SharedFunctionInfo (SFI) | 主要存放静态元数据的图纸（包含字节码与函数签名）。同一份图纸可供多个剧组实体（JSFunction）共用。 运行时会在上面挂载情报小本本。 |
| 活着的剧组实体 | JSFunction (闭包对象) | 运行期动态诞生的活物。体内缝合两根指针：一根指向公共图纸（SFI），一根持有出生地摄影棚的钥匙（Context 的引用）。 |
| 临时演员 / 龙套 | Tagged Value (标记值) | 所有 JS 值的统一物理载体。靠底层的 pointer-tagging / immediate-tag（指针标记机制）来区分小整数（Smi）与堆指针等不同表示形式。 |
| 唯一聚光灯 | Accumulator (Acc) | 舞台上的累加器。全场只有这一盏聚光灯，同一时间只能有一个值站在灯下，是所有字节码指令的核心操作锚点。 |
| 小板凳 / 休息椅 | Registers (虚拟寄存器) | 摆在聚光灯外围的椅子（r0, r1...）。用于存放局部变量或暂时退下阵来的中间计算结果。 |
| 豪华别墅 | Heap Context Slot | 为“逃逸（被闭包捕获）”的变量专门在富人区（堆内存）开辟的保留地。只要拿着钥匙的剧组还活着，别墅就不会被强拆。 |
| 情报小本本 | Feedback Vector | 解释器狂奔时动态更新的侦查记录。记录对象的形状与运行信息，为后期特效师（TurboFan）提供关键证据与优化线索。 |
| 定妆照 / 服装单 | Hidden Class / Map | 规定了演员的穿着打扮和口袋位置。注意：演员只要加减/修改一个属性（换件衣服），就必须当场换一张全新的定妆照（Map 迁移）。 |
| 特技替身 | Inline Cache (IC) | 分为：单态替身（只认一张定妆照，速度极快）、多态替身、超态替身（定妆照太乱，替身直接罢工，只能走完整查找流程）。 |
| 吹哨的警卫 | The Hole (哨兵值) | 主要看守 let/const 的未初始化状态（TDZ）。（注意：除了暴躁的吹哨子警卫，它还有另外一种用途，在这个列表后面，会详细说明）。 |
| 场记板 | Bytecode PC | 记录当前执行的字节码偏移（哪条分镜头正在执行）。解释器、错误回溯与去优化恢复时靠它精准定位回退点。 |
| 制作日程 / 微任务队 | Microtask / Job Queue | 存放 Promise.then 的回调。主调用栈清空后，微任务队会被逐条调度执行，对事件循环的可观察顺序有直接影响。 |
四、 场地与关键动作
| 片场比喻 | V8 底层实体 | 核心职责与表现 |
|---|---|---|
| 跨界防爆门 | Entry Frame (入口帧) | 砸在物理堆栈底部的厚重铁门。保存宿主调用约定与 C++ 物理现场，挡住异常穿透，保全宿主进程。 |
| 临时搭建的戏台 | JS Stack Frame | 函数 Call 时拔地而起的工作区。嵌套调用就是“戏台叠戏台”，杀青时严格按调用顺序从最上层挨个拆除。 |
| 界碑 与 戏台前沿线 | FP (帧指针) & SP (栈指针) | FP 往下看内务，往上看遗产。SP 是戏台前沿线，杀青时 SP=FP 瞬间收回前沿线，夷平整个戏台。 |
| 极速圈地 / 物理一刀 | SP = SP - Frame_Size |
解释器按图纸钢印数字，挥刀向下拉伸 SP，瞬间 O(1) 斩出戏台上所有虚拟寄存器（小板凳）的物理空间。 |
| 替身罢工 | IC Miss (缓存未命中) | 特技替身（IC）上场时，发现演员的定妆照和情报本里不一样，直接罢工。只能重新走查找流程，同时更新情报小本本。 |
| 现场无缝换角 | OSR (On-Stack Replacement) | 演极其漫长的循环戏时发生的现场换人。这是片场唯一能打破“杀青前不能换演员”规则的绝对特例。 |
| 安全绳 / 彩排录像 | Deopt Metadata | 特效师预留的回退通道。必要时借助它，将高度优化的机器码物理寄存器，精确还原回解释器的状态。 |
| 拍摄翻车与废片 | Deoptimization (去优化) | 激进特效遇到突变当场穿帮。拉拽安全绳，把控制权安全交还给解释器（Ignition），并直接把这段失效的机器码扔进垃圾桶废弃。 |
| 重拍预案 | Lazy Deopt (懒去优化) | 翻车后如果不致命，先标记当前特效失效，等这组长镜头（函数）平稳演完再回退，避免强行中断。 |
我们从开篇就一直强调， 一定要分清 规范 和 实现 的区别，在学习中， 也尽量以双视角甚至多视角来讲解。下面我们就以从解析篇到现在，已经出现很多次的 会吹哨子的警卫 这个知识点，来说明，双视角多视角的必要性。
对于数组 [1, , 3] 我们进行分析：
— 规范 / 编译期（AST 层，语法语义）
在语言/规范层面，[1, , 3] 中间的“空位”（elision）语义上就是“该索引在对象上不存在”，不是 NullLiteral 也不是显式写出的 null。解析器/Parser 在生成 AST 时会以一种占位（elision）的形式标记该位置；某些解析器实现把这个占位在 AST 的数组元素列表里表示为 null（仅作为实现细节的占位符），但这和源码中显式写的 null（NullLiteral）是不同的概念。简短检验（语义区别）如 1 in arr、forEach 的行为，会把两者明显区分开来。
二 运行期 / 引擎实现（Heap 层，物理表示）
在实际堆布局里（例如 V8 的 FixedArray backing store），不能留“物理空洞”，因此引擎用一个内部哨兵（sentinel）填充该槽——通常称为 the_hole / the_hole_value。
the_hole 不是 null、不是 undefined、也不是数值 0；它是 C++ 层面的内部标记/对象，脚本层不应直接依赖或可见它。the_hole，引擎会把该槽视为“缺失属性”，按属性查找/回退逻辑继续处理（最终由语义层返回 undefined）。the_hole 会把数组的 elements-kind 从 packed 降到 holey（如 HOLEY_SMI_ELEMENTS），这改变了底层快速路径并通常带来性能成本（对后续访问产生长期影响）。三 运行结果 / JS 语义层（表面行为）
对脚本可观察到的是：访问空位 arr[1] 返回 undefined，但这只是规范定义的回退值（因为属性不存在），并不意味着槽里真实存的是 undefined。
示例
const holey = [1, , 3];
const undef = [1, undefined, 3];console.log(1 in holey); // false — 索引不存在
console.log(1 in undef); // true — 索引存在，值为 undefinedholey.forEach(x => console.log(x)); // prints 1, 3 (跳过空槽)
undef.forEach(x => console.log(x)); // prints 1, undefined, 3
最后，语义层、编译期 AST 表示与运行期物理表示是三套不同的“视角”：AST 用占位表示缺节点；运行期用 the_hole 填槽并影响优化；JS 层最终呈现的是规范定义的 undefined 回退。写代码和做性能优化时需要以规范语义判断行为，但以引擎实现（hole → holey → 性能降级）来评估性能的结果。
js的运行场景，需要两个刚性的核心需求。
强隔离：不同的JS代码运行环境必须互不干扰，比如浏览器里两个网站的代码不能互相篡改数据、一个页面崩溃不能带崩整个浏览器；
轻量隔离：在同一个大运行环境里，需要多个独立的小执行环境，但是又不能付出过高的性能和内存开销，比如同一个页面里的多个同站iframe，不需要重新启动一整套引擎实例。
为了能满足这两个要求，v8设计了两层隔离体系
Isolate负责底层物理级别的绝对隔离，Context负责同物理实例内的逻辑级执行环境隔离。
下面我们分别学习。
一、Isolate
这里必须纠正一个常见错误：Isolate不是进程，也不是线程。一个操作系统进程里，可以创建多个Isolate实例；一个Isolate实例，对应且仅对应一个主线程，同时可以有自己专属的辅助线程。
（1）专属的堆内存（Heap）
（2）专属的垃圾回收器（GC）实例
（3）线程模型：Isolate的进入限制与后台任务
Enter并执行（需用Locker/Unlocker在多线程中同步）。这是V8的核心线程规则，Isolate本身不是线程安全的，必须通过排他锁保证同一时间只有一个线程访问，否则会直接崩溃。（1）完全不共享任何JS对象，跨Isolate无法直接传递对象引用
（2）OOM、崩溃的隔离边界
二、Context
v8::Context。它是JS代码真正的「运行容器」——哪怕你创建了Isolate，没有Context，也无法执行任何JS代码。这里我们需要理解这个设计的核心价值所在：Context是为了在同一个Isolate里，实现轻量级的全局环境隔离，避免重复创建Isolate带来的巨大性能和内存开销。创建一个新的Context，开销极小（只是创建一套新的全局环境）；而创建一个新的Isolate，需要重新分配堆内存、初始化GC、初始化一整套引擎实例，开销是Context的成百上千倍。
（1）专属的、完全独立的全局对象
window/globalThis；在Node.js环境里，是global/globalThis；在自定义Context里，你可以完全自定义这个全局对象。window.a = 123，给全局对象加了一个属性a，在同Isolate的B Context里，执行console.log(window.a)，只会输出undefined——因为两个Context的window根本不是同一个对象，就像两个摄影棚的背景板，哪怕都叫「客厅布景」，也是两个完全独立的板子，你在A棚的背景板上写字，B棚的背景板上完全看不到。window对象，就是两个不同Context的全局对象。主页面的全局变量，iframe里默认完全访问不到，反之亦然，这就是Context隔离的最直观体现。（2）内置原生对象
Array、Object、Function、String、Number、Math、JSON、Promise、RegExp等等，所有JS内置的语法相关的API，都属于这个范畴。Array与另一个Context的Array在JS语义上是不同的），这就是iframe-to-parent instanceof出现false的根本原因。arr，在主页面里执行console.log(arr instanceof Array)，结果会返回false——因为主页面里的Array构造器，是A Context的内置对象；而iframe里的数组arr，它的原型是B Context里的Array.prototype。这两个Array构造器，在JS语义上是两个完全独立的函数对象，它们的原型对象也完全独立，所以instanceof判断会失败。（3）Context的环境装配流程，以及自定义沙箱能力
一个Context的创建和环境装配，分为两个核心步骤，这也是它能实现自定义JS沙箱的核心原理：
第一定义全局对象模板：通过V8的ObjectTemplate（对象模板），预先定义全局对象可以拥有哪些属性、方法，哪些属性可读写、可配置、可枚举。你可以在这里决定，给这个Context注入哪些API，屏蔽哪些API。
第二初始化Context实例，完成环境装配：基于上面的模板，创建Context实例，V8会自动为这个Context初始化一整套完整的内置原生对象（语义层独立），同时把模板里定义的属性、方法挂载到全局对象上，最终生成一个完整的、可执行JS代码的全局执行环境。
vm模块、isolated-vm库），核心原理就是创建一个自定义Context，只给它注入允许的安全API，屏蔽掉fetch、eval、document、process等危险API，让用户的JS代码只能在这个受限的Context里运行，实现安全隔离。（1）浏览器Tab/iframe与Isolate/Context的映射
浏览器的Tab页与Isolate、Context的对应关系，受Chrome的站点隔离（Site Isolation） 机制影响，分为两种情况：
重要说明：这是Chrome的site-isolation策略带来的常见映射；具体映射依赖浏览器的进程/线程模型与隔离策略，V8只提供Isolate/Context的能力，并不强制这种对应关系。
（2）同Isolate内多Context的核心运行规则
Context::Enter()进入这个Context，执行完成后，通过Context::Exit()退出。fn，函数里写了console.log(window.a)。然后你把这个fn函数，传给同Isolate的iframe的B Context里执行。fn里访问的window，依然是A Context的window，而不是B Context的window。（3）跨Context通信
postMessage API：这是最常用、最安全的跨Context通信方式。底层原理是：V8允许在同Isolate的不同Context之间，传递结构化克隆的数据，或者可转移对象，同时浏览器会校验消息的来源、目标域名，防止恶意跨域访问。iframe.contentWindow 引用：同站iframe之间，可以通过contentWindow拿到对方Context的全局对象的有限引用，进而访问对方允许的属性、调用对方的方法。底层是V8暴露了跨Context的对象访问能力，同时浏览器会做严格的同域校验，跨域场景下会屏蔽绝大多数属性的访问。三、容易理解错误的关键知识点
错误：Isolate就是进程/线程，Context就是线程
正确：Isolate不是进程也不是线程，它是V8引擎的一个运行实例，一个进程里可以创建多个Isolate，一个Isolate对应一个主线程；Context更不是线程，它只是一个执行环境，多个Context共享Isolate的主线程。
错误：内置对象要么完全是per-Isolate，要么完全是per-Context
正确：需区分实现层与语义层。实现层V8/Isolate保有builtin的实现代码；语义层每个Context拥有独立的全局对象与内置构造器/原型，这是instanceof在不同Context不等同的根源。
错误：iframe一定是一个独立的Context，且和主页面同Isolate
正确：Chrome站点隔离机制下，跨站iframe会运行在独立的渲染进程、独立的Isolate里；只有同站iframe才是同Isolate下的独立Context。且这种映射是embedder策略，不是V8强制的。
错误：把函数传到另一个Context里执行，就会用这个Context的全局对象
正确：JS是词法作用域，函数的作用域链在创建时就绑定了所属的Context，哪怕在另一个Context里执行，依然会使用创建时的Context的全局环境。
错误：Isolate的OOM/崩溃“绝对”不会波及其他Isolate
正确：在JS语义层与正常错误范围内不会波及，但native内存越界、引擎bug或exploit仍可能影响整个进程。
错误：每个Isolate都必然拥有一组专属的OS后台线程
正确：后台线程/任务的调度与是否“专属”由V8平台与embedder决定，不能轻易下结论，前面讲过的。
错误：64位系统下V8堆上限通常为4GB
正确：堆上限与V8版本、embedder配置及运行时参数（如--max-old-space-size）有关；默认值在不同平台/版本间有较大差别，指针压缩会对最大堆规模引入工程限制（常见讨论在4GB左右），但不能将4GB作为统一默认值。
四、一段js代码的完整执行流程
我们看一段JS代码从初始化到执行的完整流程：
window，注入语义层独立的JS内置原生对象，同时挂载浏览器提供的document、location、fetch等Web API，完成全局执行环境的装配。window上，调用的Array、Object等API，都来自当前Context。window对象、内置原生对象和独立的document对象；主线程Exit主Context，Enter这个iframe的Context，执行iframe里的JS代码，两个Context的全局环境完全隔离。postMessage给iframe发消息，浏览器通过V8的跨Context通信机制，把消息数据传递给iframe的Context，触发iframe里的消息回调，回调在iframe的Context里执行。一个可执行的 Context（逻辑摄影棚），必须完成全局对象、ECMAScript 规范内置原生对象的完整装配，才能承接 JS 代码的执行。但是，规范定义了上百个内置构造器、上千个内置方法，从 Array、Object 到 Promise、JSON，每一个都需要底层 C++ 代码从零创建、初始化、挂载原型链、编译字节码。
这套标准化的繁琐装配流程，每次新建 Isolate 或 Context 时都要完整重复执行一遍，这是 V8 引擎冷启动最大的性能瓶颈。在早期无快照的版本中，桌面端创建一个 Context 需要耗时 40ms 以上，中低端移动端更是需要 270ms 以上（这些是查阅资料，找到的历史观测的估算数值，具体耗时取决于硬件平台和测量方法）。这严重降低了冷启动的体验。
而现在， V8 用来打破这个瓶颈、实现开机时间数量级缩减的，就是类似于 预制化基建 的 mksnapshot 快照机制。
我们使用 制片厂-摄影棚 的比喻：如果说 Context 的内置对象初始化，是给每个新摄影棚从零搭建标准化的背景板和道具架，哪怕所有摄影棚的基础配置完全一致，也要一钉一板的重新施工；那么 mksnapshot 就是制片厂的预制构件工厂，提前在工厂里把所有标准化基建一次性搭建完成，拍下完整的状态快照存档。新建摄影棚时，直接把预制好的整套基建搬运进场、一键还原，瞬间达到开机拍摄的标准，省去了 99% 的施工时间。
一、定义
mksnapshot 是 V8 引擎源码编译阶段的一个中间可执行程序，也是 V8 冷启动优化的核心基础设施。它的核心逻辑就是：
把 JS 运行环境的重复初始化工作，从无数次的运行期提前到一次性的编译期；把运行时需要 CPU 逐行执行代码才能生成的堆内存状态，固化成编译期预制好的二进制快照，运行时直接内存还原即可。
通俗来说，这就是餐饮行业的中央厨房预制菜模式(即星际著名的西贝模式.)：中央厨房（编译期 mksnapshot）提前把菜做好、速冻锁鲜（序列化快照），配送到各个门店（用户的宿主程序）。门店不用再洗菜、切菜、点火，只需要微波炉加热（反序列化），瞬间就能出餐，彻底解决了每个门店都要重复备菜的效率问题。
二、底层全流程：快照的生成与反序列化的物理动作
我们将快照机制分解为编译期生成和运行期还原两个核心阶段，理解底层的内存操作。
（1）编译期：快照的生成与序列化全流程
这一步发生在 V8 引擎自身的编译构建阶段，对前端开发者和最终用户完全透明。
第一步：预执行，完成虚拟世界的完整基建
mksnapshot 启动后创建一个干净的临时 Isolate 和默认 Context，执行两大核心工作：
内置对象全量装配： 从零创建规范定义的所有内置构造器、原型对象、全局 API，完成原型链挂载和属性配置。
内置函数预编译： 对所有内置方法进行解析、编译，生成对应的 SharedFunctionInfo（公共图纸，下一章核心）和 Ignition 字节码，部分核心内置函数甚至直接编译成底层可序列化的 code objects 存入快照。
至此，临时 Isolate 的堆内存里，已经有了一个无任何动态副作用的纯净 JS 运行环境。
第二步：序列化与指针重定位（核心要点）
堆内存里的对象通过指针互相引用，而指针存储的是绝对物理地址。下次新建 Isolate 时，堆的基地址完全不同，直接死板拷贝会导致指针全部失效。
mksnapshot 的序列化是一套完整的「对象图谱持久化」流程：
第三步：嵌入可执行文件
生成的快照 Blob 被转换为 C++ 巨型常量数组，随 V8 一起链接打包。当你安装 Chrome 或 Node.js 时，这个预制好的 JS 世界基建，就已经以物理数据的形式躺在二进制文件里了。
（2）运行期：快照的反序列化（开箱即用的基建还原）
这一步发生在浏览器或 Node.js 启动、新建 Isolate/Context 的瞬间。
第一步：内存拷贝与指针重定向
当宿主环境创建新 Isolate 时，V8 拒绝执行繁琐的初始化代码，而是干脆利落地执行两个物理动作：
复杂度： 这两步操作本质上是大块内存拷贝加上对快照中所有引用的一次修正（Pointer Relocation）。其耗时随快照规模线性增长（即 O(n) 复杂度）。但由于 V8 使用了大块 memcpy、只读映射和按需反序列化等极致优化，体验上能做到非常低的延迟。在桌面端耗时不到 2ms 等毫秒级别(估算值)，实现了数量级的性能跃升。
第二步：环境挂载，完成最终装配
快照只包含标准的 ECMAScript 基础状态。浏览器还需要 window/document，Node.js 还需要 global/process。
此时，V8 只需基于快照还原出的干净环境，快速创建一个全局对象并挂载这些宿主专属 API，一个完整可用的 Context 瞬间拔地而起。
三、现代 V8 的进阶优化：从全量到精细化管控
早期的快照是全量反序列化的，哪怕 90% 的内置对象（如 WebAssembly 或高级正则库）用户根本用不到，也会完整塞进内存，造成极大浪费。现代 V8 通过三招将启动速度和内存占用做到了极致平衡。
（1）懒反序列化 (Lazy Deserialization)：按需加载
这是 V8 彻底解决内存浪费的核心优化。
原理： 将完整的快照拆分成几十个独立的小块。启动时，仅反序列化最核心、最基础的极小一部分快照块。
按需触发： 当用户的 JS 代码第一次用到某个特定的内置对象时（比如第一次执行 new Promise()），V8 才会去反序列化对应的快照块并在堆里还原。完全用不到的对象，永远不会占据物理内存。
（2）只读堆快照 (Static Roots)：多实例共享的公共基建
在多 Context 或多 Isolate 场景下（如 Chrome 的多个同站 Tab，或 Node.js 的 Worker 线程），每个实例都反序列化一份完全相同的内置对象，依然是内存冗余。
原理： 现代 V8 将快照中永远不会被修改的内容（如内置函数的字节码、隐藏类 Map、undefined/null 常量等），单独剥离成一个独立的只读快照 (Read-Only Snapshot)。
共享机制： 现代 V8 可以通过操作系统的内存映射 (mmap) 实现多个实例（通常指同一进程内的多个 Isolate）对这段物理内存的直接共享；至于能否跨进程共享，则依赖宿主（如 Chrome 的进程模型）如何使用共享内存或文件映射来达成。这使得多实例场景下的基础内存开销骤降 50% 以上。
（3）自定义快照 (Custom Snapshot)：业务级冷启提速
mksnapshot 不仅能预制 V8 原生对象，还允许开发者把自己的业务代码和第三方库提前预制进去。
原理： 在应用的构建阶段，提前执行高频依赖库（如 React、Vue 或各种 Utils），生成自定义快照并打包。应用启动时直接反序列化，彻底免去了运行时的源码解析和编译时间。
战绩： VS Code、Figma 等重型 Electron 桌面应用，正是通过自定义快照，将冷启动时间砍掉了 30% 以上。（需要注意：某些系统用自定义快照确实能显著提速，但也要注意业务代码调试的复杂性与快照维护成本）。
四、使用和限制的问题：快照机制不能做什么？
快照是冷启动优化的核心关键，但是快照并不是万能的，它有严格的限制。
不能包含宿主相关的动态 API
快照只能包含与 ECMAScript 语义直接相关、且在编译期可确定为无副作用的内容。任何依赖宿主运行时信息的对象（如浏览器的 DOM 树、Node.js 的 process.pid、实时网络交互或打开的文件句柄等），都不应被写入快照，必须在运行时动态挂载。
不能包含有副作用或动态不确定的代码
预执行的代码必须是纯净无副作用的。不能包含 Math.random()、Date.now()、网络请求或文件读写。如果在编译期预制了当前时间，那用户运行时拿到的将永远是几个月前快照打包那一刻的过期时间。
跨版本不通用
快照与 V8 引擎版本是强绑定的。不同版本的 V8，其堆内存布局、对象隐藏类结构、序列化格式随时会变。跨版本使用快照会导致指针错乱，直接引发进程崩溃。
(说明：在前面的章节中提到不同 Isolate 之间完全不共享对象引用，这是准确的；但通过宿主环境提供的共享内存如 SharedArrayBuffer 或 native handle，依然可以实现跨环境的数据互通，这是独立于堆快照之外的特殊通道。)
五、快着急制的理解误区
错误 ：快照就是简单的内存镜像直接映射。
正确： 快照是经过序列化处理的对象依赖图。反序列化时必须经历严格的指针重定向计算，把相对偏移转为当前堆的绝对物理地址，绝非一句简单的 memcpy 就能搞定。
错误 ：快照能把所有 JS 代码都提前预制，启动时无需执行。
正确： 只有静态、无副作用的初始化代码有资格进入快照。动态的业务逻辑必须在运行时老老实实交给解释器执行。
错误 ：自定义快照里塞的代码越多，启动越快。
正确： 塞入过多低频代码会导致快照体积暴涨，极大地拖慢反序列化时的 I/O 读取和指针重定向耗时，反而得不偿失。
错误 ：快照反序列化出来的对象，和运行时从零创建的对象有差异。
正确： 两者在结构、行为、语义上完全一致，JS 代码完全感知不到任何区别 —— 唯一的差异就是创建速度快了几个数量级。反序列化出来的对象，同样可以正常修改、删除属性，正常调用方法，没有任何限制。
六、收工了：串联制片厂的生命周期
到这里，我们可以用完整的比喻将快照机制串联起来：
快照机制的本质，就是把重复劳动一次性前置，用编译期的一次重度计算，替换掉运行时无数次的重复初始化。
同时，快照里已经预制好了所有内置函数的 SharedFunctionInfo（公共图纸）和预编译字节码。这正是连接「编译期」与「运行期」的终极纽带。
上面的快照，核心kpi是时间，而现在，我们讲一下空间，即v8在内存的使用中是如何的扣扣嗖嗖。
JavaScript 是一门到处都是回调函数、极度依赖闭包的语言。如果每一次 function() {} 的执行，引擎都要在内存里原封不动地把庞大的指令代码复制一份，那再大的运行内存也会被撑爆。
为了将内存压榨到极致，V8 对 JS 里最核心的实体------ 函数，进行了一次分解。这就是 V8 运行期精妙的内存设计：双子星模型（SharedFunctionInfo 与 JSFunction）。
第一：SharedFunctionInfo (SFI)：公共图纸
核心内容： SFI 里面装载的全是与“单次执行状态无关”的元数据。它是一张详尽的公共建筑图纸：
为什么叫“Shared” (共享)？
想象一下，如果你写了一个高频触发的逻辑：for(let i=0; i<1000; i++) { function foo(){} }。
在 JS 的语义层面，每一次循环都会创建一个全新的、相互独立的函数对象。难道 V8 要把 foo 的字节码编译 1000 次、在内存里存 1000 份重复的死代码吗？
肯定不会！V8 对内存的控制极其抠门。对于 foo 这个函数，内存里永远只有唯一的一张 SFI 图纸。那 1000 个循环创建出来的函数实体，都会通过内部指针共享这同一张图纸。这也是它名字里 Shared 的核心由来，它极大拯救了前端应用的堆内存。
第二： JSFunction：活着的剧组与闭包的肉身
CreateClosure 这条字节码指令时，V8 才会在堆内存（通常是新生代 New Space，但具体的分配与提升行为会受 GC 与逃逸分析等优化影响）里 new 出一个真实的 JSFunction 对象。核心动作（物理缝合）： 这个新建的 JSFunction 本质上是一个“执行容器”。V8 会在它诞生的瞬间，做一次极其神圣的“缝合手术”，为其注入三大核心灵魂指针：
shared_ 指针（拿图纸）： 死死地指向那张静态的 SFI 图纸，获取函数执行的所有静态指令与元数据。context_ 指针（锁环境）： 死死地抓住当前那一刻正在运行的上下文（Context 结构）。这是 V8 最核心的一步——物理锁定函数的词法作用域。feedback_cell_ 指针（发笔记本的领取凭证）： 注意！为了极致的节约内存，V8 在初期通常只会给 JSFunction 发一个 feedback_cell 的间接引用。真正的“情报小本本”（Feedback Vector）是按需、延迟分配的。一旦分配，它将负责记录函数专属的类型情报。情报猜测的准确度，将直接决定后期特效师（TurboFan）的优化质量；而错误的猜测，则会导致去优化（Deopt）的翻车惨剧。第三：指针的力量
有很多初学者，甚至工作多年前端开发者，到处吐槽js如何的不堪，如何如何的难用，如何如何的是个缝合怪 指针如何如何的难理解难使用。。。js都默默承受着。
前端八股文里总是背诵：“JavaScript 采用词法作用域，函数的作用域在定义时决定，而非调用时决定”。很多初学者觉得这是一种语言规范的“玄学”，看不见摸不着，甚至经常和 this 的动态指向搞混。
但站在这对核心双子星面前，玄学荡然无存，只剩下冷冰冰的 C++ 指针与绝对确定的物理规则：
解释器在运行时，真正 Call 的永远是带有上下文的 JSFunction，而绝不是光秃秃的 SFI 图纸！
无论这个 JSFunction 被作为回调函数传到了多深的调用栈里，也无论它被 return 到了哪个毫无相干的外部环境去执行。只要它一启动，Ignition 解释器只会做两件固定的事：
JSFunction 里掏出 shared_ 指针，拿到预编译好的字节码和预先算好的寄存器数量，在物理栈上瞬间砸出一个栈帧（Stack Frame），完成极速内存圈地。JSFunction 里掏出那个在它出生时就被缝合进去的 context_ 钥匙，把它作为当前函数查找外部变量的唯一基准点。所有越界的变量查找，都会顺着这把钥匙指向的堆内存链条（Context Chain）向上摸索。我们用一个最经典的闭包例子，直观还原这个底层物理过程：
JavaScript
function outer() {
let a = 1;
// 解释器走到这里，执行 CreateClosure 字节码
return function inner() {
console.log(a);
};
}
const fn = outer();
fn(); // 输出 1
底层的物理动作完全对应我们的规则：
outer 执行时，解释器走到 inner 的函数声明处，触发 CreateClosure 指令，在堆内存中创建出 inner 的 JSFunction 对象。inner 的 shared_ 指针连上预编译好的 SFI 图纸；它的 context_ 指针，被 V8 强行绑定到了 outer 刚刚在堆上生成的那个包含了 a=1 的 Context 别墅上。fn 被 return 到了全局环境。此时，虽然 outer 的 C++ 物理调用栈帧已经被彻底销毁出栈，但是！ fn 身上的 context_ 指针依然像个铁锚一样，牢牢抓着 outer 留在堆内存里的那个 Context 别墅，导致它无法被垃圾回收。fn() 被调用时，解释器毫不关心当前是在全局环境，它直接掏出 fn 肚子里的 context_ 钥匙，顺着指针一开门，精准拿到了 a=1，完成打印输出。总结： 所谓“闭包”，所谓“出身决定命运的词法作用域”，在 V8 底层从来都不是什么虚无缥缈的玄学。它就是 JSFunction 对象内部，那个在 CreateClosure 执行瞬间被刻死、永远指向堆内存中某座特定 Context 别墅的 context_ 物理指针。
如果看过这系列文章的第一部分 解析篇 的朋友，可能会记得，我们在学习解析时，说过， 在预解析时，并不会生成AST，而是会生成一个占位符，并且和SFI相关联，那个时候的SFI，和这里的SFI，有神么区别吗？我们下面就详细的讲一下，把这个延续千年的恩怨给了结了。
先说结论：
它们在 C++ 的物理内存地址上，是 100% 绝对相同的同一个对象， 但是，它的内部状态和装载的数据，经历了一次从“空壳档案袋”到“满配图纸”的变化。
在 V8 的 C++ 源码中，这个过程被称为 Lazy Compilation（惰性编译）。
我们就来回顾一下SFI的前世今生
阶段一：预解析阶段 “只有封面的空档案袋”（Uncompiled SFI）
当 V8 第一次拿到一长串 JS 源码，准备开机建厂时，为了极速启动，预解析器（Pre-parser）只会对没有立即执行的函数进行极其粗略的扫描。
此时，V8 会在堆内存里 new 出一个 SharedFunctionInfo 对象。但这时候的它，是一个半成品。
这个“空档案袋”里装了什么？
foo。function foo(a, b) 就是 2。它缺少了什么最重要的东东？
CompileLazy（懒编译替身）。阶段二： 触发 CompileLazy
时间来到了运行期。代码里终于有一句 foo() 被调用了！
男一号 Ignition 解释器（或者更准确地说是执行环境）顺着 JSFunction 的指针，找到了这个 SFI 图纸。结果低头一看：“哎呀？剧本（字节码）呢？怎么是个叫 CompileLazy 的替身？”
此时，CompileLazy 被触发，V8 瞬间按下了暂停键，大喊一声：“导演，快写剧本，演员要上场了！”
阶段三： “满配的图纸”（Compiled SFI）
V8 立刻把 foo 函数的源码（根据 SFI 里记录的起止位置提取出来）重新扔给真正的 Parser 和 BytecodeGenerator（导演）。
生成了完整的 AST，接着生成了 BytecodeArray（字节码序列），并算出了 Frame Size（最高水位线）和 FeedbackMetadata（情报表格）。
v8的点睛之笔：
V8 不会去销毁那个旧的 SFI 然后创建一个新的！如果那样做，外面无数个指向旧 SFI 的闭包（JSFunction）全都会变成野指针而崩溃。
V8 的做法是：原位热更新（In-place Update）
它直接把刚刚生成好的 BytecodeArray、Frame Size 和 FeedbackMetadata，“塞进”那个预解析阶段留下的旧档案袋里，并把那个指向 CompileLazy 的占位指针，替换成真正指向字节码执行入口的指针。
总结：SFI 的“前世今生”
我们用表格对比一下同一个 SFI 对象在两个阶段的状态：
| 属性 / 内容 | 预解析阶段 (Uncompiled SFI) | 真正调用后 (Compiled SFI) |
|---|---|---|
| 片场比喻 | 只有封面的空档案袋 | 装满指令的图纸 |
| 物理内存地址 | 0x1234abcd |
0x1234abcd (同一个地址，原位更新) |
| 源码起止位置 | 已有 (记录了从哪到哪) | 保持不变 |
| 形参个数 (参数名额) | 已有 (如 2) |
保持不变 |
| AST (分镜头原稿) | 无 | 编译瞬间生成 (生成字节码后通常被丢弃) |
| BytecodeArray (剧本) | 无 | 被填入完整的字节码序列 |
| Frame Size (钢印) | 无 | 被填入确切的虚拟寄存器数量 |
| FeedbackMetadata | 无 | 被填入情报小本本的格式规范 |
| 执行入口指针 | 指向内置的 CompileLazy 替身 |
指向真正的字节码入口代码 |
那么为什么不一开始就全部编译好呢？
因为前端网页有太多类似下面这种“写了但可能永远不执行”的代码（比如点击某个冷门按钮才会触发的回调）：
JavaScript
document.getElementById('hidden-btn').addEventListener('click', function massiveFunction() {
// 几千行极其复杂的逻辑
});
如果在网页加载时，V8 就把 massiveFunction 完整编译成字节码，不仅会严重拖慢网页的首屏显示速度，还会白白浪费大量的内存，尤其是手机内存。先建个“空档案袋（Uncompiled SFI）”占着坑位，等用户真的点下按钮时再“填补剧本”，这是 V8 在极速启动与极致内存之间的平衡知道。
包装一切的 Script Function
当我们在 app.js 里写下第一行看起来自由的顶层全局代码时，比如：
JavaScript
var a = 1;
console.log(a);
很多朋友可能会以为，这些代码就像吹散的蒲公英一样，直接散落在名为“全局”的空间里。
其实并不是那样，在 V8 的底层视角里，根本不允许存在“散落代码”。
为什么不允许？
因为 V8 的整个编译流水线（从 Parser 生成 AST，到 BytecodeGenerator 生成字节码），其唯一能识别的“根节点”和“工作单元”，必须是函数（Function）。AST 树必须有一个树根，字节码序列必须有一个归属容器。它们无法接受零散的游离语句。
因此，V8 编译器在解析 JS 文件时，必须玩一个偷天换日的障眼法：它悄悄地把这整个文件里的顶层代码，全部编译成一个“类似函数”的顶级代码对象（Top-level Code Object）。在引擎内部，你可以把它视为一个隐式的 Script Function（脚本函数）。它的核心元信息（代码物理起止位置、词法作用域、包含多少个内层闭包），会被极其严谨地打上钢印，记录在对应的 SharedFunctionInfo (SFI) 图纸及 Script 结构中。
我们以为自己写的是“全局代码”，但在引擎眼里，这不过是这个庞大匿名函数肚子里的“内部逻辑（函数体）”而已。
这个 Script Function 有 3 个特殊的底层性质：
(anonymous) 时，那往往就是它的物理真身。this 指向： 在浏览器的传统 <script> 标签中，顶层 this 指向全局对象（window）。在 Node.js 普通文件（CommonJS 模块）中，顶层 this 绝对不等于 global！ 为什么？因为 Node.js 在把代码交给 V8 之前，在外部又暴力套了一层真实的字符串外衣：(function (exports, require, module, __filename, __dirname) { 你的代码 \n });。所以模块顶层的 this 实际上等同于 module.exports。在 ES 模块（type="module" 或 .mjs）中，由于模块规范要求默认处于严格语义（Strict Mode），顶层的 this 永远是 undefined。var a = 1 时，引擎实际上是在这个隐式函数执行时，顺着这根被锁死的指针，找到了全局摄影棚，并把 a 这个道具摆在了大厅的正中央。就像在我们的片场： 写了一堆零散的表演动作，制片厂绝不会让演员在马路上瞎演，它会强行给套上一个名叫《第一集：试播集》（Script Function）的剧集外壳。所有的全局动作，都不过是这一集里的剧情。
现在，剧本包装好了（Script Function），图纸（SFI）和实体（JSFunction）也都完美缝合了。但是，V8 引擎本质上只是一个被嵌入的 C++ 库，它绝对不会主动去给自己找活干。
真正掌握生杀大权、决定什么时候开机的，是宿主环境（Host Environment）——比如 Chrome 浏览器主进程，或者 Node.js 底层的 C++ 核心代码。
宿主环境，才是真正出资组建这一切的“大老板 / 制片人”。关于片场宇宙的设定，可以往上翻翻，复习一下。
不同的宿主环境，触发这声开机指令的场景也完全不同：
<script> 标签、执行 eval 动态代码、或是调用 new Function 创建函数时。node app.js 或是执行 REPL 环境中的输入代码时。（前面在讲this指向时讲过，在使用 require 加载 CommonJS 模块时，Node.js 还会给代码额外套上一层 function(exports, require, module...){} 的外衣，但剥开这层特定外衣，扔给 V8 执行的最底层机制依然同理）。当物理片厂（Isolate）建好了，逻辑摄影棚（Context）也搭好了，大老板拿着那个包装好的 Script Function 走向 V8 引擎，重重地按下了那个跨越两个世界的底层 API 按钮：
v8::internal::Execution::Call
“都出来干活了，把整个脚本跑起来！”
随着这句 C++ 代码的执行，宿主程序正式向 V8 引擎下达了开机指令。
但这同时引出了一个问题：
C++ 大老板这一个命令出来，就意味着操作系统的物理 CPU 要从执行 C++ 编译出来的机器码，瞬间切换去执行 V8 解释器里的指令了。
万一里面有个死循环，或者爆出了一个致命的未捕获错误，会不会把大老板（Node.js 或浏览器进程）直接带着一起崩溃坠崖？
为了防止这种情况，在真正拔起第一个 JS 栈帧之前，V8 必须在悬崖底下铺上一张极其厚实的“防爆缓冲垫”。
这就是跨界防爆门——Entry Frame（入口帧）。
大老板（C++ 宿主）扣动了 Execution::Call 的扳机，但操作系统的物理 CPU 并不会直接“瞬移”到 JavaScript 的代码里去执行。
因为这是两个不同的世界
C++ 代码编译出的机器码，严格遵循着操作系统底层的 应用程序二进制接口调用约定，它把极其重要的系统状态保存在 CPU 的物理寄存器里（比如 rbp 栈底指针、rsp 栈顶指针，以及各种非易失性寄存器）。
而 V8 的 Ignition 解释器，是完全不按 C++ 规则运行的野路子。一旦让它接管 CPU，它会在物理内存里疯狂圈地、读写累加器、频繁变动栈顶指针，它有自己的一套寄存器使用策略。如果直接让它冲进去，C++ 保存在物理寄存器里的核心数据瞬间就会被踩得稀巴烂。
等 JS 代码跑完，CPU 回头一看：我是谁？我在哪？C++ 的执行现场全没了。操作系统会直接报出 Segmentation fault（段错误），把整个进程当场干掉。
为了防止这种同归于尽的惨剧，在真正建立第一个 JS 栈帧之前，V8 必须在悬崖底下，铺上一张极其厚实的“防爆缓冲垫”。
C++ 与 JS 的物理界碑
在执行任何一句 JS 字节码之前，V8 会先执行一段小型汇编代码片段（Stub）——也就是 JSEntry Stub。这段极速的底层汇编跳板代码，会在操作系统的物理堆栈上，强行砸入一个极其特殊的栈帧——Entry Frame (入口帧)。
它是横亘在 C++ 静态世界与 JS 动态世界之间的一道“气闸舱”：一边连接着 C++ 的物理寄存器规则，一边连接着 JS 的虚拟栈帧逻辑。
不仅如此，它还充当了两个世界之间的“海关”。 C++ 大老板调用时传递过来的参数，通常是一个 C++ 的数组指针（argv），JS 引擎是无法直接使用的。JSEntry Stub 会在建立 Entry Frame 的同时，负责把 C++ 数组里的参数一个个取出来，严格按照 JS 的调用约定（Calling Convention）物理压入栈中，完成数据的“跨界偷渡”。
作用：物理现场的绝对冻结
Entry Frame 砸入物理栈后的第一件事，就是封存历史。
它会把 C++ 世界此刻所有关键的物理寄存器状态——包括 rbp/rsp 等栈指针，以及所有非易失性寄存器（用于保存 C++ 的局部变量和调用上下文）——原封不动地全部压入自己所在的这片栈内存中保存起来。
完成封存后，它才放心地给 Ignition 解释器放行：“去吧，尽情去折腾 CPU 寄存器吧，C++ 的老家我已经替你们锁好了。”
兜底保障：跨越生死的完美退场
Entry Frame 不仅负责把 C++ 安全地送进去，更负责把结果安全地接回来。这里有两种情况：
Return。控制流跳回 Entry Frame，它从容地从栈上把之前保存的物理寄存器数据塞回 CPU。指针一转，C++ 宿主程序就像什么都没发生过一样，拿着 JS 返回的结果继续往下跑。throw new Error("Boom!")，并且没有被任何 try-catch 捕获。
JSEntry Stub 会检查 Isolate 线程内部的 pending_exception（待处理异常）标志位。 一旦发现有致命错误，Entry Frame 会把这个致命的 Error 包装成一个安全的 C++ 可处理对象，通过宿主设置的 v8::TryCatch 机制传递出去，然后恢复 C++ 的寄存器现场，平稳地把错误交还给宿主大老板。结果就是： 这就是为什么你的 Node.js 代码报错时，终端里只会优雅地打印出一段红色的 Error 堆栈字符串然后正常退出，而不是直接让整个操作系统进程崩溃的原因。
正是 Entry Frame 的默默扛下所有，才保全了宿主进程的体面。
伴随着 Entry Frame 稳稳扎入物理内存，两个世界的安全通道彻底打通。
大老板的参数已经静静地躺在栈上，等待被认领。
控制权，正式移交给 Ignition 解释器。这中间通常通过一个名为 InterpreterEntryTrampoline 的内置代码片段作为跳板，它是通往字节码世界的第一级台阶。
第一个真正的 JavaScript 栈帧，即将拔地而起！
补充内容 ------从解析篇到现在，时间太久了，我不确定有没有写过这部分相关的内容，只记得3月份的那篇提到过栈帧大小的事，多写总比少写好。
在 Entry Frame 铺好缓冲垫、控制权刚刚交接给 Ignition 解释器的这一瞬间，时间仿佛静止了。
在解释器准备大干一场、往物理内存里圈地建栈帧之前，我们必须先回答一个直击灵魂的底层问题：
解释器怎么知道这个即将开机的“剧组（栈帧）”，到底需要多大的占地面积？它怎么知道要准备几把“椅子（参数和局部变量）”？
难道解释器要在每次函数被调用时，先临时去把函数体里的代码从头到尾扫描一遍，数一数里面有几个 let、几个 var、需要多少个临时变量，然后再决定向操作系统申请多大的内存吗？
这是不可能的。
如果把这笔账留在运行期去算，那么每次函数调用的开销就会变成 O(N)（N 为代码复杂度）。对于那些在 requestAnimationFrame 里每秒执行 60 次，甚至在 for 循环里执行千万次的高频函数来说，这种运行时的扫描损耗是灾难性的。
V8 的底层思路是：永远不要在运行期，去做任何可以在编译期完成的事。
实际上，栈帧的大小和参数的数量，早在之前的编译阶段，就已经被精确计算出来，并且作为“死数据”死死地烙印在图纸上了。
当 Parser（解析器）在编译期第一次扫过你的代码 function foo(a, b, c) 时，它就已经确定了这个剧组需要 3 个正式演员。
这个数字 3（即 FormalParameterCount）会被直接硬编码写入到这把函数的公共图纸——SharedFunctionInfo (SFI) 的元数据中。（注：除了这 3 个明面上的演员，引擎还会暗中加上 1 个隐形大佬——this 接收者，作为雷打不动的零号位参数，这个知识点，我记得前面在哪个地方讲过，好像在ignition上篇？）。
为什么必须记下这个数字？
因为 JS 是一门极其自由灵活的语言。你规定了 3 个参数，但大老板（调用者）执行时完全可能乱塞 5 个参数，或者只给 1 个参数。
在接下来的建组阶段，解释器必须拿着图纸上的这个标准数字 3，去和调用者实际压入栈的参数进行“对账（参数适配）”，以保证栈帧结构的绝对规整。
参数数量决定了栈帧的“上半部分（参数区）”，而函数内部的局部变量和临时计算，决定了栈帧“下半部分（工作区）”的大小。
在上一篇中，我们讲过场务（BytecodeRegisterAllocator - 字节码寄存器分配器）。他在陪着导演生成字节码时，干了一件极其了不起的事：极限复用。
let x，就分配一个常驻寄存器 r0。a + b，就分配一个临时寄存器 r1 暂存结果。一旦加法算完，r1 立刻被场务无情收回，借给下一行代码的乘法继续使用。在整个 AST（抽象语法树）被遍历完、最后一条字节码生成完毕的杀青时刻，场务会翻开他的账本，统计出一个决定性的数据——最高水位线（Maximum Register Count）：即在这个函数逻辑最复杂、嵌套最深的那个瞬间，同时最多需要用到多少个虚拟寄存器（这里的“同时用到”已经包含了显式局部变量和临时变量的最大并发数）。
假设场务算出来，最高水位线是 5 个寄存器。这个数字，就是作为不可篡改的物理钢印，被死死烙印在 BytecodeArray 对象头部的 frame_size，
它记录的是“需要预留的寄存器槽位个数”，而不是直接的物理字节数。
我们通过两个例子来看下计算过程：
例一：基础运算的临时借用
JavaScript
function calc(a, b) {
let x = 100;
let y = (a + b) * x;
return y;
}
那个极度抠门的场务（Register Allocator）在编译期推演：
遇到 let x = 100：分配常驻虚拟寄存器 r0。
遇到 (a + b)：借用临时寄存器 r1 存结果。
遇到 * x：将 r1 和 r0 相乘，结果放入新的常驻寄存器 r2（代表变量 y）。
推演结论： 此函数并发最高时，同时征用了 3 个虚拟寄存器。
例二 控制流分支的极限使用
很多前端以为：我声明了几个变量，就会占用几个坑位。 这样的理解是不正确的，看下面这段代码：
JavaScript
function process(type, val) {
let result = 0; // 分配 r0
if (type === 'A') {
let tempA = val * 2; // 分配 r1
result = tempA + 10;
} else {
let tempB = val / 2; // 场务极其抠门，直接复用 r1 ！！
result = tempB - 5;
}
return result;
}
在这个例子中，代码里明明声明了 result、tempA、tempB 三个局部变量。
但场务在推演时发现：tempA 和 tempB 存在于两个绝对互斥的 if/else 分支中，它们在物理时间线上永远不可能同时存活。
因此，场务会极其冷酷地让 tempA 和 tempB 共享同一个物理寄存器 r1！
推演结论： 尽管声明了 3 个变量，但这个函数的最高水位线只有 2 个虚拟寄存器（r0 和 r1）。
场务会将这个极限压榨出来的最高水位线数字（如例一的 3，例二的 2），死死地写入 BytecodeArray 的头部元数据中。
极速物理圈地
注意，图纸上记载的只是“寄存器需求数量（Metadata）”，它并不是最终的物理字节数。
当男一号登场前一瞬，InterpreterEntryTrampoline 会极速读取图纸上的 Metadata（假设最高水位线是 3 个寄存器），然后在脑子里进行一次绝对精确的汇编级心算：
(注：以下推演为一个基于 64-bit x86 架构的理想化核心模型。在真实的 V8 引擎中，实际的物理内存布局会因不同的操作系统 ABI、CPU 架构（如 ARM）以及编译器的具体优化策略而有所差异，但这丝毫不影响我们理解其 O(1) 圈地的本质。)
3 个寄存器 × 8 字节（64位系统指针大小） = 24 字节。Return Address（返回地址）Previous Frame Pointer（指向上一个栈帧的 rbp，用于异常回溯）Context Pointer（当前函数所在的逻辑摄影棚指针）JSFunction Pointer（当前正在执行的双子星实体自身的指针） 这 4 个固定槽位，占了 4 × 8 = 32 字节。最终心算结果： 24 (工作区) + 32 (固定头) = 56 字节。为了对齐 16 的倍数，最终向上补齐到 64 字节。
算完这个绝对精确的数字后，InterpreterEntryTrampoline 对物理内存挥出那极速的 O(1) 一刀，它直接将物理 CPU 的栈顶指针（比如 x64 下的 rsp）向低地址狠狠拉伸 64 个字节：
sub rsp, 64
只用了一条毫无波澜的机器指令，全场所需的所有槽位、固定帧头、运行期空间，瞬间在物理内存中拔地而起！
三万字了，又要分篇了。下篇再见。
五一快乐。
本文首发于： 掘金社区
同步发表于： csdn
码字虽不易 知识脉络的梳理更是不易 ，但是知识的传播更重要，
欢迎转载，请保持全文完整。
谢绝片段摘录。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。