php 8 的 jit 对 laravel/thinkphp 等 web 框架无提升甚至降低 qps，因瓶颈在 i/o 而非 cpu；真正有效的优化是 opcache.preload，可预加载核心类显著提效。
PHP 8 的 JIT 对 Laravel/ThinkPHP 这类框架几乎没提升
实测数据很直接：在典型的 MySQL + Redis + Nginx Web 场景中，开启 opcache.jit 后 QPS 反而下降 5%–6%，不是“没提升”，而是负优化。原因很简单——框架的瓶颈根本不在 PHP 字节码执行上，而在 I/O 等待（查数据库、读缓存、发 HTTP 请求）。JIT 编译机器码再快，也等不到 MySQL 返回结果。
- 你用
ab或wrk压测一个带 DB 查询的 API，开启 JIT 后响应时间变长、吞吐下降，这是正常现象，不是配置错了 - Laravel 官方基准测试显示：PHP 8 相比 PHP 7.4 整体快 23.5%，但这主要来自引擎优化、类型推断和
opcache.preload，不是 JIT - JIT 在 CLI 下跑纯计算脚本（如斐波那契、base64 批量编解码）能提速 2–3 倍；但在 FPM 模式下，每个请求生命周期短、热点代码难积累，JIT 很难生效
真正该开的不是 JIT，而是 opcache.preload
opcache.preload 是 PHP 8 中对 Web 框架最实在的性能改进，它在 PHP-FPM 启动时就把核心类（如 Laravel 的 Container、Application）预加载进共享内存，省去每次请求重复 include/require 和编译的开销。效果比 JIT 稳定、可预期、无副作用。
- 在
php.ini中添加：opcache.preload=/path/to/preload.php -
preload.php里用opcache_compile_file()显式加载关键文件，别用glob()扫一堆不确定的类 - 确保
opcache.enable=1且opcache.enable_cli=1（否则 CLI 下 preload 不生效） - 修改 preload 文件后必须重启 PHP-FPM，它不会自动热更
哪些场景才值得开 JIT？别猜，看代码特征
JIT 不是开关，是“偏科加速器”——只对持续占用 CPU 的密集循环有效。如果你的项目里有这些代码，才考虑启用：
- 图像处理（GD/ImageMagick 批量缩略图生成）
- 加密解密（JWT 签名验签、AES 大量加解密）
- 数学建模或统计计算（如用 PHP 写的实时风控评分逻辑）
- 自研解析器/编译器（比如 Brainfuck、DSL 解释器）
判断方法：用 xhprof 或 Blackfire 抓一次请求火焰图，如果 zend_execute_ex 占总耗时 >30%，且集中在几个函数内循环，那 JIT 才可能起作用；如果 mysqli_query、curl_exec、file_get_contents 占大头，关掉 JIT 更省心。
立即学习“PHP免费学习笔记（深入）”；
开启 JIT 的最小安全配置和常见翻车点
很多人配了 opcache.jit=1205 却没效果，是因为漏了三个硬性前提：
- 必须加载
opcache.so扩展（Docker 官方镜像默认不启！得手动docker-php-ext-enable opcache） - 必须设
opcache.jit_buffer_size=64M（值为 0 或未设置 = JIT 彻底不工作） - FPM 模式下，必须保证
opcache.enable=1；CLI 模式下，还额外要opcache.enable_cli=1 - 别信手册说“默认开启”——PHP 8.0+ 默认
opcache.jit=0，且opcache.jit_buffer_size=0，两个都得显式配
最后提醒一句：PHP 8 的升级收益，80% 来自类型系统收紧、错误语义明确、str_contains() 这类新函数减少 bug，而不是 JIT。把 ??=、match、UnionType 用顺了，比折腾 JIT 省下的时间多得多。
