opcache.jit=1235与opcache.jit=tracing本质相同，均为Tracing JIT的启用模式，区别仅在配置形式；1235中各位数字分别控制跟踪、循环优化、函数内联和寄存器分配。
PHP 8.x 的 JIT 编译器不是“开了就快”的银弹，它只对特定代码结构生效；类型系统增强则直接影响运行时行为和 IDE 支持，但不会自动修复已有逻辑错误。
opcache.jit=1235 和 opcache.jit=tracing 有什么实际区别
两者本质是同一套 JIT 引擎（Tracing JIT）的不同启用模式，区别在于编译策略的激进程度：
-
opcache.jit=tracing是字符串别名，等价于opcache.jit=1235—— 这是目前最常用、兼容性最好的配置 -
1235中每位数字代表一个开关：1启用跟踪、2启用循环优化、3启用函数内联、5启用寄存器分配；漏掉某一位（如设为1205）会禁用对应优化 - 设成
opcache.jit=off或0会彻底关闭 JIT，但opcache.enable仍可缓存 opcode - 某些旧版 PHP 8.0（如 8.0.0–8.0.2）对
tracing字符串支持不稳，建议生产环境统一用数字形式
为什么开了 JIT 但 phpinfo() 显示 jit_buffer_size=0
这说明 JIT 模块根本没加载成功，常见原因不是配置写错，而是底层依赖缺失或内存限制太低：
- 检查
opcache.enable是否为1—— JIT 依赖 Opcache，若 Opcache 关闭，JIT 自动失效 - 确认
opcache.jit_buffer_size值合理：设为0表示禁用缓冲区；10M对多数 Web 应用偏小，建议从64M起步，CPU 密集型服务可设128M或更高 - Linux 下若启用了
SELinux或grsecurity内核补丁，可能阻止 JIT 动态申请可执行内存，需调整策略或换内核 - 容器环境（如 Docker）中，
--cap-add=SYS_ADMIN或securityContext.privileged: true可能是必要条件
strict_types=1 对现有代码的真实影响范围
它只作用于声明它的那个文件顶部，并且仅约束函数调用时的参数与返回值类型检查，不改变变量赋值行为：
立即学习“PHP免费学习笔记（深入）”；
- 开启后，调用
strlen(123)会直接报Fatal error: Uncaught TypeError，而不是静默转成字符串 - 但
$x = 123; $y = $x . 'abc';依然合法 ——strict_types不影响表达式中的隐式转换 - 第三方库若未声明
declare(strict_types=1)，其内部逻辑不受你文件里该声明的影响 - 返回类型声明（如
function foo(): int）在 strict mode 下强制校验，否则仅在调用方开启 strict 时才触发检查
JIT 在真实 Web 请求中为何经常“没感觉”
因为绝大多数 PHP Web 请求的瓶颈不在 CPU 计算，而在 IO（数据库、Redis、HTTP 调用）或框架开销，JIT 对这部分无加速能力：
- 一次 Laravel 请求中，90% 时间花在
PDO::query()等待 MySQL 返回数据，JIT 编译不了网络延迟 - 模板渲染（如 Twig）涉及大量字符串拼接和数组操作，这些属于解释器友好型，JIT 优化空间极小
- 真正受益的场景很窄：图像缩放计算、JWT 签名验签循环、批量数值归一化、递归树遍历等纯 CPU 任务
- 想验证是否生效，别压测首页，改用
php -r 'for($i=0;$i 这类脚本对比耗时
JIT 编译本身有启动成本，首次请求可能变慢；类型声明带来的错误拦截虽好，但会让原本“侥幸跑通”的弱类型逻辑立刻崩掉——这两点在灰度上线前最容易被忽略。
