opcache.enable必须为1，否则JIT完全不生效；JIT深度依赖OPcache，若其禁用或未加载，JIT将静默失效，需通过opcache_get_status()['jit']验证enabled和on均为true。
opcache.enable 必须为 1，否则 JIT 完全不生效
JIT 不是独立扩展，它深度依赖 opcache。即使你配了 opcache.jit，只要 opcache.enable=0 或配置被注释掉，JIT 就不会启动——连日志都不会报错，只会静默失效。
常见踩坑点：
- 集成环境（如 XAMPP、phpstudy）里改了系统 php.ini，但实际加载的是环境自带的另一份配置，用
php --ini和phpinfo()确认真实路径 - Docker 中挂载了 php.ini，但容器内 opcache 扩展未启用，需检查
docker exec -it xxx php -m | grep opcache - CLI 场景下漏配
opcache.enable_cli=1，导致php script.php测试时 JIT 不工作
opcache.jit=1255 是 Web 服务最稳的起点
opcache.jit 是四位数字，顺序为：AVX开关寄存器分配JIT触发策略优化级别。1255 表示：
-
1：启用 AVX 指令（现代 x86 CPU 基本都支持，开启后数学运算更快） -
2：全局函数级寄存器分配（比局部 block 分配更激进，适合长生命周期请求） -
5：Tracing 模式（跟踪热点循环和调用链，对 Web 请求中反复执行的逻辑最有效） -
5：脚本级优化（基于类型推断和调用图，生成更紧凑的机器码）
别直接抄 tracing 字符串——它只是别名，底层仍映射为数字；而数字配置能精确控制行为。开发环境可先试 1205（禁用 AVX），避免某些旧虚拟机报 SIGILL。
立即学习“PHP免费学习笔记（深入）”；
opcache.jit_buffer_size 至少设为 64M，小了会降级为解释执行
JIT 编译出的机器码要存进内存缓冲区。如果 opcache.jit_buffer_size 太小，编译一半就满了，后续热点代码只能退回到 Zend VM 解释执行——你测不出性能提升，还以为 JIT 失效了。
实测建议：
- 普通 Laravel/WordPress 站点：从
100M起步 - 计算密集型服务（如风控模型、图像缩放）：设为
256M或更高 - 内存受限容器（如 512MB RAM 的 Pod）：不低于
64M，同时监控opcache_get_status()['jit']['buffer_free']，持续接近 0 就说明不够
注意：opcache.jit_buffer_size 是硬上限，不能动态扩容，重启 PHP 进程才生效。
验证 JIT 是否真在跑，别信“配置写了就行”
光看 phpinfo() 里显示 opcache.jit 值没用。必须运行代码确认 JIT 引擎已加载并正在编译：
var_dump(opcache_get_status()['jit']);
正常输出中 "enabled"=>true 且 "on"=>true 才算真正激活。如果 "buffer_free" 长期为满值（比如 "buffer_free"=>0），说明缓冲区耗尽，JIT 已自动关闭部分功能。
容易忽略的关键点：
- 首次请求不会触发 JIT 编译，得等第 2–3 次请求后，热点才被识别并编译——所以压测前务必预热
-
opcache.jit_hot_loop=64这类参数决定“多热才算热”，默认值偏保守，高并发下可适当调低（如设为 32）加快编译节奏 - JIT 对
include动态文件、eval()、反射调用等场景无效，别指望它加速路由分发或 DI 容器解析
