JIT仅在计算密集型场景提速明显，需同时满足PHP 8.1+、OPcache启用、opcache.jit_buffer_size≥64M、opcache.jit=1205等四条件，否则静默失效。
能提速，但只在特定场景下明显——不是所有代码都受益，也不是所有服务器配置都能稳定启用。
opcache.jit 配置值直接影响是否真启用 JIT
JIT 不是开个 opcache.enable=1 就自动生效的。必须显式设置 opcache.jit，且值不能为 0 或空字符串。
-
opcache.jit=tracing：启用 tracing 模式，适合长循环、递归、数学密集型逻辑（如fibonacci()、sqrt()连续调用） -
opcache.jit=1205或1235：数字模式更精细，例如1205表示启用 register allocation + loop peeling，1235还加了 type inference；数值越大越激进，但也越容易因内存或类型推断失败而退回到解释执行 -
opcache.jit=0或未设置：JIT 完全不工作，哪怕opcache.jit_buffer_size再大也无效
jit_buffer_size 设得太小会导致 JIT 静默失效
opcache.jit_buffer_size 是 JIT 编译器用来存放机器码的内存池，单位是字节（支持 M 后缀）。它不是“越大越好”，而是“至少够用”。
- 设为
1M或10M：常见于开发环境误配，实际运行中 JIT 编译器会因 buffer 不足直接放弃编译，日志里无报错，但opcache_get_status()['jit']['enabled']返回false - 生产建议值：至少
64M，计算密集型服务建议128M～256M - 注意：该内存由 PHP 进程独占，不共享，FPM worker 数 × buffer size = 实际内存占用，超限会触发 OOM 或进程崩溃
Web 请求类项目通常看不到明显提升
绝大多数 Laravel/WordPress/ThinkPHP 应用的瓶颈不在 CPU，而在 MySQL 查询、Redis 读写、文件 I/O 或网络延迟。JIT 对这部分几乎没影响。
立即学习“PHP免费学习笔记（深入）”；
- 实测数据：某 WordPress 站点开启 JIT 后，首页 TTFB 下降约 3%～5%，远低于宣传的 20%+，因为请求中 90% 时间花在
mysqli_query()和模板渲染上 - 真正受益的代码特征：
for循环 > 10⁵ 次、反复调用sin()/sqrt()/hash()、图像像素级处理、加密算法实现 - CLI 场景更明显：比如一个每小时跑一次的数据清洗脚本，含大量数组遍历+浮点运算，启用
opcache.jit=1235后耗时下降 35%
PHP 8.0+ 的 JIT 在某些扩展下可能出问题
JIT 编译依赖 Zend VM 的 opcode 稳定性，一旦扩展修改了执行流程（尤其是 hook 或拦截 opcode），JIT 可能绕过逻辑或崩溃。
- 已知冲突扩展：
xdebug（v3.0+ 默认禁用 JIT）、blackfire（分析期间 JIT 自动关闭）、phpdbg（调试时 JIT 不生效） - 自定义扩展若使用
ZEND_VM_SET_OPCODE_HANDLER或重写execute_ex，需确认是否兼容 JIT 编译后的机器码路径 - 验证是否真生效：运行
php -r "var_dump(opcache_get_status()['jit']);"，检查enabled为true且buffer_free明显小于buffer_size
最常被忽略的一点：JIT 编译是“按热区触发”的，冷代码永远不编译；而且首次请求仍要走完整解释流程——所以压测前务必预热，否则看到的只是“未优化状态”的性能。
