必须通过opcache_get_status()['jit']运行时返回值确认JIT真实状态，若为NULL、空数组或enabled=false则未启用；常见原因包括opcache.enable=0、jit_buffer_size未设或为0、CLI下未启用opcache.enable_cli。
怎么确认JIT到底有没有真正启用
别信phpinfo()里写的“JIT enabled”，那只是说明扩展编译进去了。真实状态得看运行时返回值：opcache_get_status()['jit']。如果返回NULL、空数组，或enabled为false、on为false，说明压根没跑起来。
常见失效原因包括：
-
opcache.enable=0（哪怕opcache.jit=1255也白搭） -
opcache.jit_buffer_size=0或未设置——默认就是0，JIT直接静默禁用 - CLI模式下漏了
opcache.enable_cli=1，php -r里查不到JIT状态 - PHP是Alpine镜像编译的，没加
--enable-opcache-jit，PHP_JIT常量都不存在
CLI下快速验证JIT是否起效的压测脚本
Web请求太短，JIT根本来不及热身。必须用CLI跑一个持续、重复、计算密集的循环，才能看出差异。
下面这段代码可直接保存为bench.php，分别在开/关JIT下执行：
立即学习“PHP免费学习笔记（深入）”；
<?php
function calc_loop($n = 1000000) {
$sum = 0;
for ($i = 0; $i < $n; $i++) {
$sum += sin($i) * cos($i);
}
return $sum;
}
<p>$start = microtime(true);
for ($i = 0; $i < 5; $i++) calc_loop(1000000);
$end = microtime(true);
echo "5次循环总耗时: " . round($end - $start, 3) . "s\n";
?>关键点：
- 必须调用多次（至少3–5轮），让JIT有足够机会识别热点并编译
- 单次
calc_loop(1000000)比calc_loop(100)更可靠——太小的循环JIT可能根本不介入 - 对比命令示例：
php -d opcache.enable=1 -d opcache.jit=1255 -d opcache.jit_buffer_size=256M bench.phpvsphp -d opcache.enable=1 -d opcache.jit=0 bench.php
JIT开启后反而变慢？先排查这三个硬伤
实测中QPS下降5%、响应时间上涨不是玄学，而是有明确触发条件：
- 请求生命周期太短（平均<50ms），JIT编译开销（监控+生成机器码）超过执行收益
- 大量动态行为：比如
eval()、$func()、__call、__invoke，JIT会主动绕过整段函数，还额外消耗判断成本 - 内存吃紧时，
opcache.jit_buffer_size=256M占满后触发频繁GC，反而拖累整个进程
典型负优化场景：Laravel API接口（含Eloquent查询+JSON响应）、WordPress首页渲染、Nginx+PHP-FPM短连接服务——这些都不是JIT该发力的地方。
哪些场景真能拿到3倍性能提升
JIT只对“CPU一直在算，几乎不等IO”的代码敏感。以下场景实测有效：
- 图像批量缩放/滤镜（GD或Imagick内部循环）
- 自定义序列化器（深度遍历+类型推断+字符串拼接）
- 静态分析工具（如PHP-Parser遍历AST节点做规则检查）
- 加密运算（AES-CBC多轮迭代、RSA大数模幂）
- 数值模拟（蒙特卡洛积分、粒子系统更新）
注意：即使在这些场景，也要确保函数被反复调用（而非每次请求新建对象+销毁），否则JIT热身失败，效果归零。FPM worker刚启动的前几十个请求，opcache_get_status()['jit']['hot_functions']基本为空——这不是配置错，是机制使然。
