PHP 8.0+才支持JIT，低版本无效；需同时启用opcache.enable=1、设置opcache.jit_buffer_size>0、选择tracing/function模式，并通过opcache_get_status()验证jit键及compiled_functions增长。
PHP 8.0+ 才支持 JIT，低版本直接无效
PHP 的 JIT（Just-In-Time）编译器从 PHP 8.0 开始实验性引入，PHP 8.1 起才默认启用部分优化路径。如果你用的是 PHP 7.4 或更早版本，无论怎么配置 opcache.jit 都不会生效——扩展本身不存在。
验证方式很简单：
php -v
输出中必须包含 Zend Engine v4.0.0（对应 PHP 8.0）或更高版本。同时确认 opcache 已加载：
php -m | grep opcache
启用 JIT 不只是开开关，关键看这 4 个 ini 配置
JIT 行为由 opcache.jit 控制，但它依赖其他几个 opcache 设置协同工作。漏掉任意一个，JIT 可能静默降级为纯解释执行。
立即学习“PHP免费学习笔记（深入）”；
-
opcache.enable=1：必须开启 OPcache，JIT 是其子功能 -
opcache.enable_cli=0（或1，按需）：CLI 模式默认关闭 JIT，如需命令行测试得显式打开 -
opcache.jit_buffer_size=256M：必须 > 0，否则 JIT 直接禁用；太小（如1M）会导致频繁 recompile，反而拖慢性能 -
opcache.jit=tracing或opcache.jit=function：推荐初试用tracing，它对循环/分支多的代码更友好；function模式只 JIT 单个函数入口，适合短生命周期脚本
典型安全配置示例：
opcache.enable=1 opcache.enable_cli=0 opcache.memory_consumption=256 opcache.jit_buffer_size=256M opcache.jit=tracing
不是所有代码都能被 JIT 加速，别对 Web 请求抱太高期待
JIT 对 CPU 密集型、长循环、数学计算类逻辑（比如图像处理、加密、数值模拟）效果明显；但对典型 Web 应用——大量 IO（MySQL 查询、cURL、文件读写）、框架路由、模板渲染——几乎无感，甚至因 JIT 编译开销略增首字节时间。
常见误判场景：
- 用
ab或wrk测简单phpinfo()，发现 QPS 没变化 → 正常，这种脚本太短，JIT 来不及热启动 - 在 Laravel/WordPress 中开启 JIT 后，页面加载时间不变 → 正常，瓶颈在 MySQL 或 autoload，不是 PHP 字节码执行
-
opcache.jit_debug=1输出大量jit: compiled N functions，但实际耗时没降 → 说明编译了，但热点没打在 JIT 覆盖路径上
调试 JIT 是否真在跑，看这三个信号
光改配置不等于 JIT 在工作。确认它活跃的最可靠方式是查运行时指标：
- 调用
opcache_get_status()，检查返回数组中的jit键：$status = opcache_get_status(); var_dump($status['jit']);
若为null，说明 JIT 未启用或初始化失败 - 观察
opcache.jit_hot_func（默认 64）和opcache.jit_hot_loop（默认 64）是否被触发：只有函数被调用超阈值、或循环迭代超阈值，才会进入 JIT 编译队列 - 设置
opcache.jit_debug=1并查看错误日志（非 stdout），会打印类似jit: start compilation of foo() (line 12)的记录 —— 但注意，这会显著降低性能，仅用于验证
JIT 编译本身有延迟，首次请求几乎看不到收益；持续压测 30 秒以上，再比对 opcache_get_status()['jit']['compiled_functions'] 增长量，才是真实依据。
