PHP 7.4升至8.4性能提升显著，但需正确配置：启用opcache.jit=1235、opcache.jit_buffer_size≥256M，并避免eval等JIT禁用场景，否则QPS无改善甚至下降。
PHP 7.4 升级到 8.4，不调配置基本白升；真正带来性能收益的不是版本号，而是 opcache.jit 是否启用、opcache.jit_buffer_size 是否够大、以及代码是否落在 JIT 能覆盖的路径上。
为什么有些项目升级 PHP 8.4 后 QPS 没变化甚至更慢
这不是 PHP 退化，而是运行时条件没对齐：
-
opcache.validate_timestamps=1在生产环境开着——每次请求都扫文件修改时间，稳稳吃掉 5–15ms -
opcache.jit没设或设成0——PHP 8.4 的 JIT 默认就是关的，opcache.jit=1235才算真正启用 - 大量使用
eval()、动态类名（new $className）、匿名函数绑定（Closure::bind）——JIT 默认跳过这些，旧版解释器反而没这层判断开销 - 第三方扩展（如老版本 Swoole、自研 PDO 封装）未适配 PHP 8.3+ 的
Error统一异常机制，触发降级 fallback，执行路径变长
opcache.jit 参数怎么选才不踩坑
opcache.jit 是整数策略编码，不是开关。不同值对性能影响极大，且和业务特征强相关：
-
opcache.jit=1205：适合 CPU 密集型任务（如报表生成、图像处理），启用函数内联 + 循环优化，但首次请求 JIT 编译延迟略高 -
opcache.jit=1235：推荐用于 Web API 场景，增加调用计数触发条件，平衡冷启动与长稳态性能；实测 Laravel API 平均快 9% -
opcache.jit=1255：启用全部优化（含寄存器分配、逃逸分析），但缓冲区压力大，opcache.jit_buffer_size必须 ≥256M，否则频繁回收反拖慢 -
opcache.jit=0或未设置：JIT 完全不工作，PHP 8.4 退化为“带更好类型系统的 PHP 8.3”
哪些场景真能感受到明显提升
性能跃升集中在三类可被 JIT 实际覆盖的用户态计算逻辑：
立即学习“PHP免费学习笔记（深入）”；
- 函数调用密集型：模板渲染、ORM 查询构建、嵌套 foreach + 条件判断——8.4 比 7.4 快约 2.1×，主因调用栈精简 + 参数解析优化
-
对象序列化/反序列化：如
json_encode($hugeArray)、unserialize($raw)——8.4 快 1.8×，得益于zend_string内存布局重构 + 引用计数延迟释放 -
纯计算循环：数值累加、浮点迭代（如
calculate_pi()）、字符串批量处理——开启opcache.jit=1235且opcache.jit_buffer_size≥256M时，比 7.4 快 2.6×；若缓冲区
数据库操作（PDO::query()、mysqli_query()）几乎无加速，因为耗时卡在 I/O 和系统调用，JIT 编译不到那里。
最容易被忽略的配置项
真正卡住性能的往往不是版本号，而是这几个常被漏掉的点：
-
opcache.jit_buffer_size=256M：低于 64M 会导致 JIT 频繁回收，中大型项目建议直接设为 256M -
realpath_cache_size=4096K：默认 4K，文件路径解析频繁时会成为瓶颈，尤其 Composer 自动加载多的项目 -
opcache.preload：对 ORM 场景收益远超 JIT，预加载Entity类、Facades、Model，避免每次请求重复反射 -
opcache.max_accelerated_files设太小（如默认 2000）：Composer vendor 有上万文件，缓存溢出导致频繁淘汰
升级后第一件事不是压测，是确认 phpinfo() 里 JIT 显示 enabled，且 opcache.jit_buffer_size 和 realpath_cache_size 真的生效了。
