PHP8 JIT默认不生效，仅对长时间CPU密集型任务有效，需显式配置opcache.jit=1255等参数并重启进程，且受编译选项、内存设置及动态语法限制。
PHP8 JIT 不是“开箱即用的性能火箭”
它确实存在，但默认不生效，且对绝大多数 Web 请求场景几乎没提速。JIT 的核心价值不在 $_GET 处理或 echo 模板渲染上，而在于长时间运行的 CPU 密集型任务——比如图像批量处理、数学建模、自定义序列化器、静态分析工具本身。
- PHP 启动时需显式启用：
opcache.jit=1255或更激进的opcache.jit=tracing（不是仅设opcache.enable=1） - 必须配合
opcache.enable_cli=1才能在 CLI 下测试 JIT 效果；FPM 模式下还需确认opcache.preload未干扰 JIT 编译时机 - JIT 编译产物不跨进程共享，每个 FPM worker 独立热身，刚启动的 worker 无任何 JIT 优化
为什么 php -v 显示 “with Zend OPcache v8.x” 却没 JIT？
因为 JIT 是 OPcache 的一个可选子模块，默认编译时可能被禁用，或运行时未触发条件。最直接验证方式是运行：
php -r "var_dump(opcache_get_status()['jit']);"
若返回 NULL 或空数组，说明 JIT 根本没工作。常见原因包括：
- PHP 编译时未加
--enable-opcache-jit（尤其 Alpine Linux 官方镜像常省略） -
opcache.jit_buffer_size=0或设得太小（至少需64M，256M更稳妥） - 代码中用了
eval()、动态函数名调用（$func()）、或太多__call魔术方法——JIT 会主动绕过这些“不可预测”路径
opcache.jit 那串数字（如 1205、1255）到底什么意思？
它是位掩码组合，顺序固定：optimization_level+on_func+register_intercept+buffer_size_flag。日常只需记两个常用值：
立即学习“PHP免费学习笔记（深入）”；
-
1205：启用 tracing JIT + 中等优化级，兼容性最好，适合生产环境试探 -
1255：tracing + 更高优化级（含循环展开、类型推测），但可能因过度优化引发极少数边界行为变化（比如浮点计算顺序微调） - 别用
0或纯字母模式（如tracing）——某些 PHP 版本解析异常，坚持用数字更稳
修改后必须重启 PHP 进程（systemctl restart php-fpm 或重载容器），opcache_reset() 不重置 JIT 状态。
压测发现开启 JIT 反而变慢？先看这三点
这不是错觉，尤其在短生命周期请求（平均
- 单次脚本执行时间
- 请求高度随机（如每个 URL 对应不同路由逻辑），JIT 没机会积累热点代码，缓存命中率趋近于 0
- 内存压力大时，JIT 编译占用的额外内存（
opcache.jit_buffer_size）可能触发更频繁的 GC，拖累整体响应
真要验证效果，得用 CLI 跑一个持续 10 秒、循环调用同一段计算逻辑的脚本，再比对 time php bench.php 结果——Web 场景下，与其押注 JIT，不如先确认 opcache.preload 和 realpath_cache_size 是否调优到位。
