PHP 8.4 比 7.4 快约 2.3 倍，但需启用 JIT（如 opcache.jit=1235）并合理配置 OPcache；分段跃升为：7.4→8.0（+18%）、8.0→8.1（+12%）、8.1→8.3（+15%）、8.3→8.4（+22%）。
PHP 8.4 比 7.4 快约 2.3 倍（典型 Web 请求场景），但这个数字只在 JIT 启用、OPcache 配置合理、且代码路径能被 JIT 有效覆盖时才成立。盲目升级版本不调配置，可能只快 10% 甚至没变化。
PHP 7.4 到 8.4 的实际响应时间落差有多大
不是线性增长，而是分段跃升：7.4 → 8.0（+18%）、8.0 → 8.1（+12%）、8.1 → 8.3（+15%）、8.3 → 8.4（+22%）。关键差异点集中在三类操作：
- 函数调用密集型逻辑（如模板渲染、ORM 查询构建）——8.4 比 7.4 快 2.1×，主要受益于调用栈精简和参数解析优化
- 对象序列化/反序列化（
json_encode/unserialize）——8.4 比 7.4 快 1.8×，因zend_string内存布局重构 + 引用计数延迟释放 - 纯计算循环（如数值累加、字符串拼接）——JIT 起效最明显，8.4 开启
opcache.jit=1235后比 7.4 快 2.6×；但若禁用 JIT 或缓冲区太小（opcache.jit_buffer_size），优势基本消失
为什么有些项目升级 PHP 8.x 后反而变慢
常见原因不是 PHP 本身退化，而是运行环境或代码适配出问题：
-
opcache.validate_timestamps=1在生产环境未关，导致每次请求都检查文件修改时间，吞掉 5–15ms - 用了大量
eval()或动态类名（new $className），JIT 默认不编译这类代码，而旧版解释器反而没这层开销 - 框架或扩展仍基于 PHP 7.x 编译（比如某些自研 Swoole 扩展未适配 8.3 的 Error 异常统一机制），触发降级 fallback 路径
- 错误启用了
opcache.jit=off或设成0，等于白升版本——PHP 8.4 的 JIT 默认仍是关闭状态，必须显式开启
opcache.jit 参数怎么选才不踩坑
opcache.jit 是整数编码策略，不是开关。不同值对性能影响极大，且和业务特征强相关：
立即学习“PHP免费学习笔记（深入）”；
-
opcache.jit=1205：适合 CPU 密集型任务（如图像处理、报表生成），启用函数内 + 循环优化，但首次请求 JIT 编译延迟略高 -
opcache.jit=1235：推荐用于 Web API 场景，增加调用计数触发条件，平衡冷启动与长稳态性能，实测 Laravel API 平均快 9% -
opcache.jit=0或未设置：JIT 完全不工作，PHP 8.4 退化为“带更好类型系统的 PHP 8.3” - 缓冲区必须够大：
opcache.jit_buffer_size=256M是多数中大型项目的下限，低于 64M 会导致 JIT 频繁回收，反而拖慢
真正卡住性能的往往不是 PHP 版本号，而是 opcache.jit_buffer_size 设太小、realpath_cache_size 没调、或者压根忘了开 JIT。这些细节在 php.ini 里只有三行，却决定你能不能拿到标称的 20%+ 提升。
