PHP 8.3 JIT 正确配置是 opcache.jit=1255 且 buffer_size≥256M，禁用 Xdebug 和 realpath_cache_size=0；仅当 opcache_get_status()['jit'] 显示 enabled=true、on=true 且 buffer_free 明显小于 buffer_size 时才真正生效。
JIT 不是开个开关就提速的，PHP 8.3 开启 JIT 后变慢、不生效、压测无提升，90% 是因为配置错用了 tracing 或缓冲区太小，而不是 JIT 本身有问题。
opcache.jit=1255 还是 tracing？别再抄错配置了
很多人在 php.ini 里写 opcache.jit=tracing，结果发现首页首屏延迟翻倍、QPS 下降。这是因为 tracing 模式会全程追踪每次函数调用路径，对 Web 请求（平均 20–50ms）来说，编译开销远大于收益。
-
opcache.jit=1255才是 Web 场景的合理选择：启用函数内联（2）、循环优化（5）、类型特化（5），但跳过全路径追踪，编译延迟低、命中率高 -
1255中的 “1” 表示启用，“2” 是函数内联，“5” 是循环优化，“5” 是类型特化；不是位掩码，顺序不能错 - 别用
1235：它强制开启“调用栈重写”，在 Laravel/Swoole/大量匿名函数项目里容易触发 JIT 编译失败 - 如果你用 Swoole 或 Fiber 协程，改用
1205（关闭循环优化，避免协程切换时缓存失效）
opcache.jit_buffer_size 至少要设成 256M
宝塔面板默认推荐 opcache.jit_buffer_size=64M，这是个危险下限值。JIT 编译后的机器码长期驻留缓冲区，一旦满，就会反复回收和重编译热点函数——你看到的“开了没提速”，主因就在这儿。
- 低于
64M：JIT 根本不启动，PHP 日志报Failed to allocate JIT buffer -
64M–128M：仅支撑单体小应用，压测时每秒回收 3–5 次 JIT 缓存 - 中大型 Web 服务必须 ≥
256M：覆盖 90% 以上热点函数，回收频率降至可忽略水平 - 别设成
1G以上：超过物理内存压力或导致 OOM，256M–512M 是生产环境实际安全区间
Xdebug 和 realpath_cache_size=0 是 JIT 的隐形杀手
哪怕你在 php.ini 里写了 xdebug.enable=0，只要 zend_extension=xdebug.so 这行还存在，OPcache 和 JIT 就被彻底禁用——PHP 内部机制决定：Xdebug 加载即接管 opcode 执行链。
立即学习“PHP免费学习笔记（深入）”；
- 必须注释掉所有含
xdebug的zend_extension或extension行，不只是设off -
realpath_cache_size=0（常见于开发环境）会让每次include/require都触发磁盘stat调用，高并发下直接吃掉 8–15ms/TTFB - 正确做法：
realpath_cache_size=4096K（不低于 2MB），搭配realpath_cache_ttl=300 - 确认
opcache.enable_cli=0：Web 场景必须为 0；CLI 下 JIT 无效，设 1 反而干扰 FPM
怎么确认 JIT 真的在跑？别只看 phpinfo
访问 phpinfo() 页面看到 “OPcache JIT: Enabled” 并不等于 JIT 在工作。真正要看的是运行时状态，尤其缓冲区是否被有效利用。
- 写个脚本执行
var_dump(opcache_get_status()['jit']);，关键字段必须同时满足："enabled"=>true、"on"=>true、"buffer_free"值明显小于"buffer_size" - 如果
"buffer_free"接近"buffer_size"，说明 JIT 编译极少发生，大概率是配置未生效或代码没触发 JIT 条件 - 压测前务必用
ab或wrk发起真实请求，静态页面或单次 CLI 脚本无法体现 JIT 对高频函数的累积优化效果 - 注意：JIT 主要加速计算密集型逻辑（如 token 校验、JSON 解析、循环处理），对纯 I/O 或数据库瓶颈型接口几乎无感
最常被忽略的一点：JIT 编译只发生在 OPCache 缓存命中的前提下。如果 opcache.revalidate_freq=0 且文件频繁变更（比如热更新、CI/CD 部署未清缓存），JIT 缓存会被连带失效——这时得同步检查 opcache.validate_timestamps 和部署流程。
