TurboFan 加速关键在于代码稳定性而非单纯高频调用，依赖执行热度、时间局部性与类型稳定性三者叠加判断；需稳定热点模式、避免去优化诱因，并善用 Sparkplug 提升冷启动性能。
要让 TurboFan 真正为你加速，关键不是“写快”，而是“写稳”——让引擎能持续信任你的代码行为，从而完成从字节码到高度优化机器码的跃迁。它不靠固定调用次数触发，而依赖执行热度、时间局部性与类型稳定性三者叠加判断。
识别并稳定热点代码的执行模式
TurboFan 不会等函数被调用一万次才行动。它在运行中持续采样调用栈，重点关注：某段逻辑（如循环体或函数入口）是否在最近 100ms 内被执行 ≥50 次；单次平均耗时是否超过 50μs；是否处于稳定调用链中（无原型变更、无 new.target 切换、无未解析动态 import）。循环比普通函数调用更容易触发，因为回边（back-edge）执行天然具备高频+局部性特征。
- 用
%OptimizeFunctionOnNextCall(fn)主动标记单次调用触发优化，配合--allow-natives-syntax启动 d8 或 Chrome 的调试能力 - 避免在热点路径中混用类型，例如同一参数一会儿传数字、一会儿传字符串，这会直接导致去优化（deoptimization）并退回 Ignition 解释执行
- 减少 try-catch 块包裹热点逻辑，异常处理会干扰控制流分析，阻碍 TurboFan 升级至高阶 IR 层
配合 Ignition 收集高质量类型反馈
Ignition 是 TurboFan 的前置探针。它一边执行字节码，一边记录类型反馈（feedback），比如 add(1, 2) 多次执行后，引擎会假设“add 的两个参数极大概率是小整数（Smi）”。这些反馈是 TurboFan 生成高效机器码的基础假设。
- 保持参数类型收敛：对数值运算，优先使用整数或统一浮点格式；对对象访问，避免在同个属性名上频繁切换数据类型（如先赋 string，再赋 number）
- 避免隐式装箱/拆箱：
obj.x + 1中若obj.x是字符串，会触发 ToNumber 转换，破坏类型稳定性 - 用
%DebugPrint(fn)查看当前函数的优化状态（unoptimized / optimizing / optimized / lazy deoptimized）和反馈向量内容
规避常见去优化诱因
一次去优化，意味着已编译的机器码失效，执行流瞬间切回字节码，性能断崖下跌。很多看似无害的写法，恰恰踩中 TurboFan 的敏感红线。
- 不要在热点函数中修改对象原型链，例如
Object.prototype.foo = ...或给构造函数加新方法 - 避免在循环内使用
arguments、eval、with，它们会禁用优化编译 - 慎用
for...in遍历非固定结构对象；改用Object.keys()+for或直接索引访问更可控 - 构造函数中避免根据参数动态决定返回值（如
return typeof x === 'object' ? x : new X(x)），这会让 TurboFan 无法确定实例类型
利用 Sparkplug 加速冷启动与中等热度路径
V8 在 2025 年后引入 Sparkplug 作为 Ignition 与 TurboFan 之间的轻量编译层。它不追求极致优化，但能在数毫秒内产出比字节码快 2–3 倍的中间代码，特别适合中等热度或需快速响应的场景。
- Sparkplug 会自动启用，无需手动干预，但它的存在降低了 TurboFan 的启动门槛——一段代码只要重复执行 ≥5 次，就可能先进入 Sparkplug 流水线
- 若你关注首屏加载性能，可优先保障核心渲染逻辑满足 Sparkplug 触发条件（短函数、少分支、类型干净），而非强求 TurboFan 全面接管
- Chrome DevTools 的 “Performance” 面板中开启 “JavaScript samples” 和 “V8 compile tasks”，可直观看到 Sparkplug 编译与 TurboFan 优化的时间分布
