PHP 8 严格类型化为何导致旧代码崩溃?

PHP 8 的类型系统强化并非简单的语法修补，而是一次执行模型的根本性调整。旧代码之所以崩溃，根源在于 PHP 7.x 时代宽松的类型协变规则和隐式转换机制被系统性收紧，那些依赖运行时自动修正的脆弱逻辑在严格模式下直接暴露为致命错误。

最典型的断裂点出现在函数签名与参数传递环节。PHP 7 中，将 null 传递给声明为 string 类型的参数只会产生警告，程序继续执行；而在 PHP 8 中，这会被直接判定为 TypeError 异常，导致执行流中断。同样，返回值类型声明也从建议性约束变为强制性校验——子类重写父类方法时，如果返回值类型不完全匹配，过去仅触发弃用提示，现在则直接抛出致命错误。这意味着大量基于旧版框架或 CMS（如 WordPress）二次开发的代码，只要存在类型声明不严谨的插件或主题，就会在升级后瞬间白屏。

另一个高频崩溃源是隐式数字转换规则的改变。PHP 8 不再容忍字符串与数字间的非严格比较中那些模棱两可的行为，例如将非数字字符串与整数进行算术运算时，原本会产生 E_WARNING 并返回 0，现在则抛出 ValueError。那些在业务逻辑中大量依赖 empty() 或 == 进行模糊判断的遗留代码，会因为这种语义收紧而出现条件分支失效，进而引发数据写入错误或逻辑死循环。

更深层的问题在于动态属性的废弃。在 PHP 7 中，可以随时向对象实例动态注入未定义的属性，这在大量使用魔术方法的旧系统中是常见模式。PHP 8.2 彻底移除了这一能力，任何对未声明属性的赋值都会触发 Error。这意味着那些通过动态属性传递状态或缓存数据的模块，必须重构为使用显式属性定义或容器模式，否则连基本的实例化都无法完成。

因此，旧代码在 PHP 8 下的崩溃并非偶然兼容性问题，而是类型系统从“宽容建议”向“严格契约”范式转换的必然结果。修复这些问题的本质，是将代码从依赖运行时隐式行为的松散结构，迁移到编译时即可校验的强类型约定上。这要求开发者在升级前通过静态分析工具（如 PHPCompatibility）全面扫描类型声明缺失、参数传递不一致以及动态属性使用点，逐项补全类型约束，而非简单修改版本号后被动应对白屏。