必须用组合策略主动暴露PHP 8.0兼容性问题：先用PHPCompatibility扫描全量代码（含模板、CLI、测试），再在PHP 8.0环境开启全量错误日志捕获运行时行为变化，最后手动验证match、联合类型、构造器属性提升等新特性及业务逻辑偏移风险。
直接跑起来会报错，但光看报错不够——PHP 8.0 的兼容性问题很多是静默变更（比如未定义数组键从 Notice 升级为 Warning，或字符串下标访问直接 Fatal error），必须用组合策略主动暴露。
用 PHPCompatibility 扫描全部代码
这是最省力的第一筛，能提前发现 80% 的语法/函数级不兼容点：
- 安装命令：
composer require --dev phpcompatibility/php-compatibility:"^10.0.0@dev" - 扫描整个
src/目录是否兼容 PHP 8.0：phpcs --standard=PHPCompatibility --runtime-set testVersion 8.0 src/ - 重点盯紧报告里的
PHPCompatibility.Functions.RemovedFunctions（如each()、create_function()）、PHPCompatibility.Variables.StringOffsetAsArray（字符串当数组访问）和PHPCompatibility.Operators.ArrayKeyExistsOnString（对字符串用array_key_exists()） - 别只扫
src/：模板文件（.php后缀的视图）、CLI 脚本、tests/下的测试用例也要覆盖
在 PHP 8.0 环境里开全量错误报告
静态扫描漏掉的运行时行为变化，得靠真实执行+日志捕获：
- 临时在入口文件（如
public/index.php）顶部加：error_reporting(E_ALL); ini_set('display_errors', '0'); ini_set('log_errors', '1'); - 触发所有核心路径：登录、表单提交、API 接口、后台任务、异常流程（如上传空文件、传非法 ID）
- 检查错误日志里是否出现：
Undefined array key（PHP 8.0 默认警告）、Cannot use string offset as array（字符串下标访问）、Deprecated: Function xyz() is deprecated（虽不中断但需处理） - 特别注意 JSON 处理：
json_decode()返回null时是否做了=== null判断（PHP 7.3+ 对无效 JSON 更严格）
验证关键语言特性变更是否踩坑
PHP 8.0 的几处“温柔陷阱”容易被忽略，必须手动构造用例验证：
立即学习“PHP免费学习笔记（深入）”；
-
match表达式替代switch：确认所有match分支都覆盖了可能值，否则抛UnhandledMatchError（不是Exception，不能用catch (\Exception $e)捕获） - 联合类型（
string|int）：调用方传入0或"0"时，是否因类型校验失败而中断；返回值是否严格满足声明（比如方法声明返回string|null，但实际返回了false） - 构造器属性提升（
public function __construct(private string $name) {}）：检查类中是否还有传统写法的属性赋值逻辑与之冲突 - 对象转字符串：未定义
__toString()的类被强制转换（如(string)$obj）会直接抛Error，而非 PHP 7.x 的E_RECOVERABLE_ERROR
真正难搞的不是报错，而是那些没报错但逻辑已偏移的地方——比如数组比较规则变化导致权限判断失效、is_countable() 替代 count() 前置检查时漏掉 null 分支、或者 str_contains() 在低版本环境直接 Fatal。这些必须结合业务场景做定向验证，不能只依赖工具。
