直接在目标环境运行并用工具扫描比仅看文档更可靠；PHP 8.2 兼容性问题主要源于废弃特性、扩展行为变化和静态分析盲区，需结合 phpcs + PHPCompatibility 扫描、composer platform 模拟及运行时验证三步落实。
直接在目标环境跑起来，再用工具扫一遍潜在风险点，比光看文档靠谱得多。PHP 8.2 的兼容性问题大多出在废弃特性、扩展行为变化和静态分析盲区，不是语法报错才叫不兼容。
用 phpcompatibility 扫描代码中的硬伤
这是最快速暴露 PHP 版本迁移问题的方式。它能识别已被移除的函数（如 create_function）、弃用警告（如动态属性）、以及新版本强制要求的写法（如 date.timezone 必须设置）。
- 安装：运行
composer require --dev phpcompatibility/php-compatibility - 扫描命令示例：
phpcs --standard=PHPCompatibility --runtime-set testVersion 8.2 ./src（把./src换成你的代码目录） - 注意区分 ERROR 和 WARNING：ERROR 级基本会崩溃，WARNING 级可能只是日志里多条提示，但 PHP 8.3+ 很可能升级为致命错误
- 别跳过
--runtime-set testVersion参数——漏设会导致扫描结果完全失效
用 composer platform 模拟低版本环境验证依赖
很多“兼容性问题”其实不是代码写的不对，而是 Composer 在你本地高版本 PHP 下装了只兼容 8.2+ 的包，一换到生产环境就挂。用 platform 强制模拟目标环境，让依赖解析提前失败。
- 在
composer.json的config节点下加："platform": { "php": "8.2.0" } - 执行
composer update --dry-run，看是否出现无法满足的依赖冲突 - 如果项目需同时支持 8.1 和 8.2，可在 CI 中用不同
platform配置反复 install + test，而不是靠人肉记忆哪些包有版本墙 - 切忌在生产环境用
--ignore-platform-reqs硬顶——这等于把炸弹埋进上线流程
运行时验证动态属性和只读类行为
PHP 8.2 对动态属性发出 Deprecated: Creation of dynamic property 警告，且 8.3+ 将直接报错。这类问题不会在静态扫描里出现，必须实际运行触发。
立即学习“PHP免费学习笔记（深入）”；
- 找项目里所有没声明属性的类（尤其是 DTO、响应类、空基类），加最小测试片段：
$obj = new YourClass(); $obj->fake_prop = 'test'; // 写入 echo $obj->fake_prop; // 读取
- 检查是否定义了
__set/__get，或显式声明了public $fake_prop；两者皆无，就必须改 - 对需要保留灵活性的类，用
#[\AllowDynamicProperties]替代压制警告——注解必须带反斜杠前缀，且只能放在class关键字正前方 - 别依赖
error_reporting设置来“隐藏”警告：PHP 8.2 默认不显示E_DEPRECATED，需显式开启error_reporting = E_ALL | E_DEPRECATED
真正容易被忽略的是运行时行为差异：比如 mb_strpos 在 GBK 环境下搜中文可能偏移错乱，或者 file_get_contents 读取 Windows 换行符后没做 str_replace 统一，导致后续字符串搜索失败。这些不会被任何扫描工具捕获，只能靠真实数据流验证。
