Sparkplug 通过绕过解释器调度开销和字节码解码瓶颈加速执行，不进行任何优化（如控制流分析、内联、死代码消除），仅将字节码线性映射为机器码，编译延迟仅10–50微秒，适用于短生命周期脚本。
Sparkplug 为什么不做优化却能加速执行
Sparkplug 的“加速”不是靠优化，而是靠绕过解释器的调度开销和字节码解码瓶颈。Ignition 解释器每次执行字节码都要查表、分派、维护执行上下文；而 Sparkplug 直接把字节码 for 循环一遍，每个字节码指令对应一个硬编码的机器码发射函数（比如 Ldar → mov rax, [rbp+8]），跳过所有中间表示（IR）和类型推导，生成的代码几乎就是字节码的线性映射。
- 它不分析控制流图，不内联函数，不消除死代码，也不做任何类型反馈驱动的特化
- 编译延迟极低：一个中等函数（200 字节码）通常在 10–50 微秒内完成编译
- 生成的机器码体积略大于 Ignition 字节码，但执行时省掉了每条指令的 dispatch 开销（实测可降 30%–50% 的指令调度成本）
- 适用场景明确：短生命周期脚本（如 CLI 工具、SSR 渲染、单次页面加载逻辑），这些场景根本等不到 TurboFan 启动
Sparkplug 和 TurboFan 的分工边界在哪
V8 不是“选一个编译器”，而是按热度逐级升级：Ignition → Sparkplug → Maglev → TurboFan。Sparkplug 的触发阈值比 TurboFan 低得多，且不依赖类型反馈稳定——只要某函数被调用约 10 次（具体值由 V8 运行时动态调整），就可能进 Sparkplug；而 TurboFan 通常要 >100 次 + 类型收敛后才介入。
-
sparkplug编译的是已存在的字节码，所以它完全复用 Ignition 的解析结果（变量位置、作用域链、this 绑定方式） -
turbofan编译时会重新建图、做类型推测、插入去优化桩（deopt bailouts），因此必须等待反馈数据积累 - 如果你写了一个只运行 1 次的
setTimeout回调，它大概率永远只走 Ignition；但如果被重复触发 15 次，很可能升到 Sparkplug，但几乎不会到 TurboFan - 用
%OptimizeFunctionOnNextCall强制触发 TurboFan 对 Sparkplug 函数无效——V8 会先等它自然热起来
实际调试中怎么确认某段代码进了 Sparkplug
Chrome DevTools 的“Performance”面板看不到 Sparkplug 编译事件，得靠 V8 内置的调试标记：
- 启动 Chrome 或 Node.js 时加参数：
--trace-opt --trace-ic --trace-turbo-sparkplug - 在 DevTools Console 中执行
%GetOptimizationStatus(func)，返回值1表示 “function is compiled with Sparkplug”（注意：不是3，那是 TurboFan） - 若看到日志里出现
[Sparkplug] compiling function xxx，说明已进入，但若紧接着有[TurboFan] optimizing xxx，说明它很快又被升级了 - 常见误判点：
eval或Function构造的函数默认禁用 Sparkplug（因无法静态确定作用域），这类代码即使调用多次也卡在 Ignition
Sparkplug 的设计哲学很务实：它不试图让 JS 跑得像 C++，而是让“原本慢得不值得优化”的代码，快得足够摆脱解释器拖累。真正容易被忽略的是——它的存在本身，让 V8 可以更早放弃解释，也更晚才需要启动重型优化器。这在 SSR、微前端、CLI 等短任务场景里，影响远比 benchmark 数字更实在。
