PHP 8.2 的 JIT 在 Web 请求中基本无效，仅对纯计算、无 I/O、循环稳定的 CLI 场景有效；真实性能提升主要来自 opcache.preload 和引擎优化，而非 JIT 本身。
PHP 8.2 的 JIT 对绝大多数 Web 请求没加速效果，甚至拖慢 QPS；所谓“比 7.4 更强”，只在极少数 CPU 密集型场景下成立——而且必须满足三个硬性条件：代码可被 JIT 捕获、OPcache 配置正确、运行环境不干扰编译过程。
为什么 ab/wrk 压测带数据库的 API 时 JIT 反而更慢
典型 Laravel/ThinkPHP 接口的耗时中，mysqli_query、redis->get、curl_exec 占比常超 70%，CPU 执行 PHP 字节码的时间不到 10%。JIT 编译机器码再快，也得等 MySQL 返回结果。实测开启 opcache.jit=1205 后，QPS 下降 5%–6%，不是配置错，是瓶颈根本不在这里。
容易踩的坑：
-
opcache.jit_buffer_size设太小（如默认的 16M），JIT 缓冲区满后直接退回到解释执行 - Docker 容器里用
tmpfs挂载/tmp但限制了大小，JIT 编译产物写不进去，日志里静默失败 - 没开
opcache.preload，类加载开销远大于 JIT 带来的收益，掩盖了任何潜在提升
什么 Benchmark 脚本能真实反映 JIT 效果
必须满足：纯计算、无 I/O、循环体稳定、执行时间 >100ms。比如：
立即学习“PHP免费学习笔记（深入）”；
function fib(int $n): int {
return $n <= 1 ? $n : fib($n - 1) + fib($n - 2);
}
$start = hrtime(true);
fib(42);
echo (hrtime(true) - $start) / 1e+6 . " ms";
这类递归或长循环才可能触发 JIT 热点编译。内置函数如 sin()、pi() 单次调用永远不进 JIT，因为 JIT 不编译单次调用，只编译高频循环体内的指令流。
关键判断依据：
- 用
Blackfire或xhprof抓火焰图，zend_execute_ex占总耗时 >30% - 热点集中在几个函数内（如
fib、my_sin），而非扩展调用 - CLI 模式下跑，且已启用
opcache.enable_cli=1
PHP 8.2 JIT 比 7.4 “强”的真实来源
PHP 7.4 根本没有 JIT，所以所谓“更强”其实是 8.2 的 JIT + 引擎优化 + opcache.preload 共同作用的结果。单独拎出 JIT，它在 FPM 模式下几乎不生效——每个请求生命周期太短，来不及积累热点。
真正起效的组合是：
-
opcache.preload预加载核心类，省掉每次require和编译开销 -
opcache.jit=1235（8.2+ 推荐值），比 8.0 默认的 1205 多了寄存器分配和循环展开 -
opcache.jit_buffer_size=256M，确保足够空间缓存编译产物 - 关闭
xdebug，否则 JIT 直接禁用
别信“PHP 8.2 比 7.4 快 2.3 倍”这种笼统说法
这个数字来自特定基准测试（如 Brainfuck 解释器、矩阵运算），前提是关闭所有 I/O、预热 OPcache、CLI 模式、且 JIT 缓冲区充足。Web 场景下，你看到的响应时间下降主要来自 opcache.preload 和引擎类型推断优化，不是 JIT。
最容易被忽略的一点：opcache.preload 文件修改后必须重启 PHP-FPM，它不会自动重载——很多人改了 preload.php 却没重启，然后误以为 JIT 没效果。
