opcache.enable=1是启用OPcache的前提,但JIT需显式配置opcache.jit(如1255或tracing)、opcache.enable_cli=1(CLI验证必需)及足够大的opcache.jit_buffer_size(推荐256M),并确保opcache.so加载顺序正确、无xdebug等干扰扩展。

opcache.enable=1 是基础,但默认不启用 JIT
PHP 8.0+ 内置的 opcache 默认只做字节码缓存,opcache.jit 默认是关闭的。即使你开了 opcache.enable=1,JIT 也不会自动生效——它需要显式配置,且依赖 opcache.enable_cli=1(CLI 模式下测试才可见效果)和合适的触发策略。
常见错误:只改了 opcache.enable=1 就以为“加速完成”,结果 php -v 里看不到 with Zend OPcache v8.x 后面带 JIT 字样,说明 JIT 根本没加载。
-
opcache.enable=1(必须,Web 和 CLI 均需) -
opcache.enable_cli=1(CLI 下验证 JIT 是否工作必需) -
opcache.jit=1255(推荐初值:1=on, 2=register allocation, 5=function inlining, 5=loop unrolling) -
opcache.jit_buffer_size=256M(太小会导致 JIT 回退到解释执行,256M是较稳起点)
jit=1255 和 jit=tracing 的实际差异在哪
opcache.jit=1255 是“function-based”模式,对已知热点函数做编译;而 opcache.jit=tracing 是运行时动态追踪热路径,适合长生命周期服务(如 Swoole、PHP-FPM 持续请求),但首次冷启动可能略慢,且内存占用波动更大。
真实场景中,tracing 在高并发 Web 接口下更容易触发有效优化,但若你的脚本多为短命 CLI 工具(如 Composer、PHPStan),1255 更稳定——tracing 可能根本来不及收集足够 trace 就退出了。
立即学习“PHP免费学习笔记(深入)”;
-
1255:适合大多数传统 FPM/CLI 场景,兼容性好,效果可预期 -
tracing:需搭配opcache.jit_hot_func=127(默认 127,即调用 127 次触发 JIT)、opcache.jit_hot_loop=64等微调才易见效 - 二者不可同时启用,
opcache.jit是单值字段
为什么 phpinfo() 显示 opcache 启用,但 JIT 不生效
最常被忽略的是 opcache.so 加载顺序和 zend_extension 路径。PHP 启动时若 opcache.so 被其他扩展(如 xdebug)覆盖或加载失败,JIT 就不会初始化,但字节码缓存仍可能工作——这就造成“有 opcache,无 JIT”的假象。
验证方式不是看 phpinfo() 里的开关,而是运行:php -d opcache.enable_cli=1 -d opcache.jit=1255 -r "echo 'ok';",再检查 strace -e trace=mmap,mprotect php ... 是否出现大量可执行内存映射(JIT 编译产物)。
- 确认
extension=opcache.so在php.ini中位于所有zend_extension=行之前 - 禁用
xdebug或blackfire等干扰 Zend 扩展后再测 JIT -
opcache.jit_debug=1会输出 JIT 编译日志到 stderr(仅 CLI),可用于确认是否真正触发
opcache.revalidate_freq=0 不等于“永不检查”,还有 realpath_cache 干扰
很多人设了 opcache.revalidate_freq=0 就以为文件变更完全不检测,其实 PHP 还受 realpath_cache_ttl 影响——如果文件路径经过 symlink 或 chroot,而 realpath_cache_ttl=30(默认值),OPcache 仍可能因路径解析失败导致缓存失效或跳过 JIT。
更隐蔽的是,某些部署工具(如 Capistrano、rsync --delete)会先删旧目录再建新目录,导致 stat() 返回 ENOENT,OPcache 误判为文件被删,清空对应缓存条目,JIT 编译代码也一并丢失。
-
realpath_cache_ttl=7200(2 小时)比默认 30 秒更适合生产静态部署 - 避免在运行中直接
rm -rf代码目录;用原子软链切换(如ln -sf release-20240501 current) -
opcache.validate_timestamps=0才真正关闭时间戳校验(配合revalidate_freq=0使用)
eval()、create_function() 或反射调用的代码,JIT 会直接降级为解释执行——这点很容易被压测数据掩盖,得看 opcache.jit_bisect 或 perf profile 才能确认实际编译率。











