ignition 和 turbofan 是 v8 中协同工作的执行阶段：ignition 作为字节码解释器快速启动并收集类型/调用反馈，turbofan 基于这些反馈对热函数（如调用超100次）进行优化编译；二者输入输出紧密衔接，feedback vector 惰性积累，影响优化时机与稳定性。
Ignition 和 TurboFan 不是并列的两个独立模块，而是 V8 引擎中紧密协作的执行阶段：代码先由 Ignition 解释执行并收集运行时反馈，再由 TurboFan 基于这些反馈进行针对性优化编译——没有 Ignition 的热路径标记，TurboFan 很可能“无从下手”。
Ignition 解释器到底在做什么？
Ignition 是一个字节码解释器，它不直接生成机器码，而是把 JS 源码编译成紧凑、平台无关的字节码（如 Star r0、Ldar a1），再逐条解释执行。它的核心任务不是追求单次执行速度，而是快速启动 + 低成本收集类型与调用信息。
常见错误现象：console.time() 测出首次执行很慢，但后续变快——这往往不是缓存导致，而是 Ignition 在前几次运行中已记录了 foo 函数里 x 总是 number 类型、arr 总是 Array 实例等反馈，并将这些信息写入函数对象的 feedback vector。
- 使用场景：所有 JS 函数首次执行、短生命周期脚本、未达优化阈值的冷函数
- 性能影响：解释开销比直接执行机器码高，但启动延迟极低（相比全量编译）
- 关键点：Ignition 的字节码是 TurboFan 的输入来源之一，不是中间废料
TurboFan 编译器何时介入？编译什么？
TurboFan 不编译原始 JS 源码，也不编译 AST，而是以 Ignition 生成的字节码 + 运行时反馈（feedback vector）为输入，生成高度特化的机器码。它只对被标记为“hot”的函数做这件事，触发条件通常是该函数被调用超过 100 次，或某循环体执行超 1000 次。
常见错误理解：“TurboFan 把 JS 编译成汇编”——实际它编译的是字节码图（bytecode graph），再经多轮 IR 变换（如 JSNativeContextSpecialization、EscapeAnalysis）消除冗余、内联、去虚拟化，最终生成 x64/ARM 指令。
- 参数差异：可通过
--trace-opt查看哪些函数被优化，--trace-deopt查看为何又被退化回 Ignition 执行 - 兼容性影响：若某函数因
typeof x === 'object'后又突然传入string，TurboFan 生成的代码会触发deoptimization，控制权交还 Ignition，并更新 feedback，下次可能生成更宽泛的优化版本 - 注意：
eval、with、过于动态的try/catch会直接禁用 TurboFan 优化
如何验证当前函数走的是 Ignition 还是 TurboFan？
V8 提供了几个轻量级运行时指令，不需要改代码、也不依赖 DevTools：
- 在 Node.js 中启动时加
--print-bytecode --trace-ignition，可看到[generating bytecode for function: foo]及每条字节码 - 加
--trace-opt --trace-deopt，若输出[optimizing: foo / ...]即表示 TurboFan 已介入；若出现[deoptimized: foo, reason: Insufficient type feedback]，说明反馈不足导致退化 - 在 Chrome DevTools 的
Performance面板录制后，展开 Bottom-Up，查找CompileScript（Ignition 阶段）、OptimizeFunctionOnNextCall或OptimizeScript（TurboFan 阶段）
别依赖 console.log(new Error().stack) 判断执行路径——它只反映调用栈，不体现底层执行引擎切换。
真正容易被忽略的是 feedback vector 的“惰性积累”特性：一个函数即使被调用了 99 次，只要没触发优化，它的 feedback 就不会被 TurboFan 读取；而一旦第 100 次调用触发优化，TurboFan 会把之前全部 99 次收集的 feedback 一次性拉进来分析。这意味着局部数据污染（比如某次传了异常参数）可能延迟暴露，直到优化真正发生。
