V8的50次/100ms是动态启发式阈值而非固定值，受内存压力、CPU负载和逆优化冷却期三重压制，实际触发依赖Ignition栈顶采样与滑动时间窗口统计。
它不看“调用多少次”，而看“最近100ms内这段代码是不是反复被执行且够重”。
为什么 V8 的 50 次/100ms 不是固定门槛
这个数字只是 V8 启动 TurboFan 优化编译的常见启发式起点，不是硬编码常量。实际触发受三方面动态压制：
- 内存压力大时，阈值自动上浮，避免 CodeCache 溢出
- CPU 负载高时，编译线程被节流，采样窗口拉长
- 同一函数若刚被逆优化（deoptimization）过，会进入冷却期，短期内不再尝试编译
你用 --trace-opt 看到的 optimizing: foo (hot)，背后是 Ignition 解释器持续在栈顶采样 + 时间滑动窗口统计，不是靠一个计数器累加到 50 就立刻开干。
循环体比函数调用更容易触发优化
JIT 对“执行密度”的敏感度远高于“调用次数”。一个空 for (let i = 0; i 可能在第 3 轮迭代就进 TurboFan；而一个每秒调用 200 次、但每次只做 <code>return x + y 的函数，可能永远卡在 Ignition 字节码解释阶段。
立即学习“Java免费学习笔记（深入）”；
- 回边（back-edge）执行次数是核心信号：每次循环末尾跳回开头算一次
- V8 默认对回边计数启用更激进的采样频率，比方法入口调用计数早得多
- 含
try/catch或with的循环，即使高频也大概率被跳过——控制流不可预测
类型不稳定会让优化直接失效
哪怕某段代码稳稳达到 50 次/100ms，只要出现以下任一情况，JIT 就不会升到深度优化层，甚至会降级回解释执行：
- 参数类型在多次调用间变化（如一会儿传
number，一会儿传string） - 对象属性访问模式漂移（
obj.a→obj.b，或新增未定义字段） - 原型链在运行中被修改（
Object.prototype.x = ...） - 使用了未解析的
import()或eval，导致作用域链无法静态推断
你可以用 %DebugPrint(foo)（V8 内部函数，需 --allow-natives-syntax）查看当前函数是否处于 OptimizedFunction 状态，以及被逆优化的次数。
观察优化是否真正生效，别只信日志
--print-opt-code 或 --trace-opt 输出里看到 opt: foo 并不等于性能提升。真正关键的是：
- 该函数是否被内联进其调用者（查
--trace-inlining输出里的inline标记） - 生成的机器码是否消除了类型检查（比如没有大量
CompareNil或CheckInstanceType指令） - CodeCache 是否已满：
jstat -compiler <pid>中failed列非零说明有热点被拒编译
最易被忽略的一点：优化后的机器码默认不带调试信息，一旦你打断点或开启 debugger，V8 会立即退回到解释执行——这不是 bug，是设计使然。
