V8的JIT编译关键在于执行行为变化：函数从慢变快、内存出现新代码段、类型反馈触发；可通过Performance面板标记、%GetOptimizationStatus、--trace-opt日志及--print-code汇编输出等可观测机制确认。
识别 V8 的 JIT 编译过程，关键不是“看到机器码”，而是观察代码执行行为的变化——尤其是函数从慢变快、内存中出现新代码段、以及类型反馈被触发的信号。V8 不会暴露原始机器码，但提供了可观测的机制和典型表现。
看函数是否进入优化编译（TurboFan）
V8 对“热点函数”（被多次调用或长时间运行的函数）自动触发 TurboFan 优化。你可以通过以下方式确认：
- 在 Chrome DevTools 的 Performance 面板中录制一段脚本运行，然后查看火焰图：若某函数下方出现
TurboFan或Optimized code标记，说明它已被编译为机器码 - 在函数开头加
%NeverOptimizeFunction(fn)（仅限--allow-natives-syntax启动的 V8，如 Node.js 加--allow-natives-syntax），再对比执行时间——禁用优化后明显变慢，就反向印证了原函数确实在走 JIT 路径 - 使用
%GetOptimizationStatus(fn)查看当前状态：1表示已优化，0表示未优化，3表示正在优化中（需配合调试标志）
观察字节码到机器码的转化时机
Ignition 解释器先执行字节码，并持续收集类型反馈（比如 a 总是 number，obj.x 总是 string）。当某函数调用次数超过阈值（默认约 100 次），V8 就用这些反馈驱动 TurboFan 编译：
- 字节码本身可通过
%DisassembleFunction(fn)查看（需启用 natives syntax），输出类似Ldar a0; Add a1; Return的指令序列 - 一旦 TurboFan 完成编译，同一函数再次调用时将跳过字节码解释，直接跳转到内存中生成的机器码地址执行——这会导致执行耗时骤降，且 CPU 时间集中在 native code 区域
- 这种切换是静默的，但可通过
--trace-opt --trace-deopt启动参数在终端看到日志，例如：[TurboFan] Optimizing: fnName或[Deoptimized] fnName
借助调试工具验证机器码存在
虽然不能直接读取 x86/ARM 指令，但可间接确认机器码已生成并驻留内存：
- 在 Node.js 中运行时添加
--print-code，V8 会把 TurboFan 生成的汇编代码（非机器码，但非常接近）打印到控制台，包含寄存器分配、跳转标签和实际指令，如movq rax,[rbp+0x18] - 使用 Chrome 的 Memory 面板 → Code Flights，可筛选出“Compiled code”类型的内存块，其大小、生命周期与你调用的热点函数强相关
- 配合
--jitless参数强制关闭 JIT，若代码明显变慢（尤其循环密集型），就说明平时确实依赖了 TurboFan 编译的机器码
注意几个典型误判点
有些现象看似像 JIT，实则不是：
- 函数首次执行慢、后续变快？可能是隐藏类（hidden class）稳定或内联缓存（IC）生效，不一定是 TurboFan 参与
- DevTools 显示“Compiled”字样？那只是指字节码已生成，不是机器码；真正优化需看 “Optimized” 或 “TurboFan” 标签
- 用了 WebAssembly？那是 AOT 编译，和 V8 的 JIT 无关，不要混淆
