<p>PHP 8 是性能与行为的重大分水岭，需重点验证 JIT 配置、??= 和 count(null) 兼容性、联合类型严格模式启用；DateTime 重构提升性能并提前报错；mysql_* 函数已移除，旧代码易静默崩溃。</p>
PHP 8 不是 PHP 7 的“小改版”，而是有明确性能断点、语法契约升级和运行时行为变更的分水岭。升级前必须确认 JIT 是否生效、??= 和 count(null) 是否触发兼容性报错、联合类型是否在 declare(strict_types=1) 下启用——否则新特性等于没用，还可能埋下静默 bug。
JIT 编译器只对纯计算有效，I/O 场景别指望它提速
PHP 8 的 opcache.jit 默认不生效，必须同时配齐两个 ini 项：opcache.jit=1255 和 opcache.jit_buffer_size=256M。漏一个，JIT 就只是个开关灯泡。
- 真正受益的代码：高频递归（如
fibonacci(40)）、密集循环（如累加百万整数）、数学运算（如矩阵变换） - 完全不受益的代码：数据库查询（
PDO::query()）、文件读写（file_get_contents()）、HTTP 请求（curl_exec()）——这些耗时在系统调用，JIT 编译不了内核态逻辑 - 副作用：内存占用固定多出 15–20MB，小容器（如 128MB 内存的云函数）可能直接 OOM
DateTime 类底层重写，非法日期报错提前、format() 快 35%
PHP 8 对 DateTime 做了四层 C 层优化，不是“修修补补”，而是重构解析路径和内存布局。
- 构造非法日期（如
new DateTime('2023-02-30')）：PHP 7 走完全部校验才抛Exception；PHP 8 在字符串预检阶段就终止，省掉 70% 解析开销 -
$date->format('Y-m-d H:i:s')：PHP 7 动态拼接、多次 malloc；PHP 8 预算缓冲区大小，单次连续写入 - 切换时区（
$date->setTimezone(new DateTimeZone('Asia/Shanghai'))）：PHP 7 每次查 tzdata；PHP 8 首次加载后固化 UTC 偏移，后续仅改指针 -
clone $date：PHP 7 复制整个时区规则数组；PHP 8 只保留时间戳、时区 ID、当前偏移，内存降 62%
联合类型和命名参数能少写 bug，但依赖严格模式和 IDE
联合类型（如 string|int|null）和命名参数（如 mysqli_query(query: $sql, connection: $conn)）本质是把隐含接口契约显性化，但它们不是“自动防错”。
立即学习“PHP免费学习笔记（深入）”；
- 必须开启
declare(strict_types=1)，否则联合类型形同虚设——传个bool进int|string参数，PHP 7/8 都会静默转成1或'' - 命名参数不能混用位置参数在后：
foo(1, name: 'x')直接报错，必须全位置或全命名 - 联合类型不支持空格：
array | string语法错误，必须写成array|string - IDE（如 PHPStorm）需更新到支持 PHP 8 的版本，否则无法跳转、补全、标红错误
升级最容易踩的坑：??=、count(null)、错误转异常
这些不是“新功能”，而是行为变更点，老代码一跑就崩，且错误信息不直观。
-
??=运算符：PHP 7 解析为语法错误；PHP 8 才合法。但若你用字符串拼接模拟（如$a = $a ?? 1），升级后可能被误替成$a ??= 1，逻辑突变 -
count(null)：PHP 7 返回0；PHP 8 抛TypeError。所有未判空就直接count($arr)的地方都要补is_array($arr)或$arr ?? [] - 很多原本
E_WARNING的场景（如parse_url(null)）在 PHP 8 改为抛ValueError异常，没 try-catch 就 crash -
mysql_*函数已被彻底移除，不是弃用警告，是 fatal error
最危险的不是“PHP 8 新特性不会用”，而是“PHP 7 旧写法在 PHP 8 里行为变了却没察觉”。上线前务必跑真实请求流量，而不是只测单元用例——尤其关注日志里有没有新增的 TypeError 或 ValueError。
