opcache.jit=1235是位掩码组合，表示启用JIT编译器（1）、寄存器分配（2）、热点追踪（32）和高级IR优化（1024）；需同时满足opcache.enable=1、jit_buffer_size≥64M、CLI下enable_cli=1且PHP≥8.0非ZTS版，再通过php -r验证enabled为true才算生效。
PHP JIT 不是靠“学语法”掌握的，它不改变你写代码的方式，而是靠配置、验证和场景识别来生效。没配对参数或没验证状态，写得再规范也白搭。
opcache.jit=1235 这串数字到底代表什么
opcache.jit 的值不是版本号，而是位掩码组合，每一位控制一类优化行为：
- 第1位（1）：启用JIT编译器本身（必须为1）
- 第2位（2）：启用寄存器分配（显著减少内存访问）
- 第3位（4）：启用循环优化（如循环展开、不变量外提）
- 第4位（8）：启用函数内联（但PHP中受限较多，实际效果有限）
- 所以 1235 = 1 + 2 + 32 + 1024 → 启用基础编译 + 寄存器分配 + 热点追踪（32对应tracing模式）+ 高级IR优化（1024）
常见误区是把 1235 当成“万能值”。其实：
- CLI 脚本跑数学计算，
1255（加了循环展开）可能更快 - Web 请求为主、函数调用深，
tracing字符串模式更稳，避免某些扩展（如 xdebug）崩溃 -
0或空值 → JIT 完全不加载，php -i | grep jit会静默消失
为什么改了 php.ini 但 opcache_get_status()['jit'] 仍是 disabled
JIT 是 OPcache 的子系统，依赖多个开关同时为真，缺一不可： -opcache.enable=1（必须，否则整个 OPcache 停摆）
- opcache.jit_buffer_size ≥ 64M（设为 0、1M 或未定义 → JIT 被跳过，无报错）
- CLI 场景下还需 opcache.enable_cli=1（否则 php -v 看不到 JIT 生效痕迹）
- PHP 版本 ≥ 8.0，且不是 ZTS（线程安全）构建版（部分 Linux 发行版默认用 ZTS，JIT 不支持）
验证命令要分两步：
php -i | grep -E "(opcache.jit|opcache.enable|opcache.jit_buffer_size)"再运行：
php -r "var_dump(opcache_get_status()['jit']);"输出
["enabled"]=>bool(true) 才算真正就位。
哪些代码真能被 JIT 加速，哪些根本不会进编译流程
JIT 只编译“热点路径”，不是所有函数都进机器码。它只盯三类东西： - 频繁执行的循环体（比如for($i=0; $i）
- 被调用超过阈值（默认约 100 次）的纯函数（不含 <code>echo、file_get_contents 等 I/O 操作）
- 类型稳定的算术密集逻辑（整数累加、矩阵运算、哈希计算）
明显不会触发 JIT 的情况：
立即学习“PHP免费学习笔记（深入）”；
- 函数里含
var_dump()、error_log()、curl_exec()—— JIT 直接放弃整条路径 - 参数类型频繁变化（如传入
int又传string），导致类型推测失败 - 使用了
eval()、create_function()或动态方法调用（$obj->$method()）
一个可靠测试方式：
php -d opcache.enable=1 -d opcache.jit_buffer_size=100M -d opcache.jit=1235 -r "
\$t = microtime(true);
for (\$i = 0; \$i < 1000000; \$i++) { \$s += \$i * 2; }
echo microtime(true) - \$t;"
对比关掉 JIT 的耗时，差值 >15% 才说明 JIT 真在干活。
JIT 最容易被忽略的一点：它不解决 I/O 瓶颈，也不加速 autoload 或 Composer 加载。如果你的瓶颈在数据库查询或 API 调用，开 JIT 几乎没感知——先用 xhprof 或 blackfire 定位真实热点，别盲目调参。
