php 8.5 下 yii 2.0.49 需修复四类 runtime 风险：禁用动态属性访问、修复 reflectionparameter 类型解析异常、规避 foreach 遍历 null 致命错误、清除高危反序列化入口，否则将导致服务不可用。
在 PHP 8.5 环境下运行 Yii Framework 2.0.49 时，必须同步修复因版本适配不全引发的三类 runtime 风险：动态属性触发 fatal error、ReflectionParameter::getType() 返回类型校验中断、以及 foreach 遍历 null 值直接崩溃——这些不是警告，而是服务不可用的硬性中断。
禁用动态属性访问（PHP 8.2+ 强制要求）
Yii 2.0.49 虽移除了核心类中的隐式动态属性，但自定义组件或第三方扩展仍可能通过 __get()/__set() 写入未声明属性。PHP 8.5 默认将此类操作视为 Error，直接终止脚本执行。
方法一：修改入口文件（推荐快速验证）
打开 web/index.php 或 console/yii，在
ini_set('error_reporting', E_ALL & ~E_DEPRECATED);
方法二：永久关闭（生产环境必须）
编辑 php.ini，找到 zend.enable_gc 行，确保其值为 1；再添加一行：
zend.assertions = -1
重启 PHP 进程生效。若遗漏此步，某些依赖 assert 的扩展（如 codeception）会在运行时抛出 AssertionError。
方法三：代码层兜底（针对遗留组件）
检查所有继承自 yii\base\Object 的自定义类，显式声明所有可能被 __set() 赋值的属性：
public $config; public $cacheKey; public $enum; ——注意：enum 是 PHP 8.1+ 保留字，【严禁用作属性名】，否则 class 加载即失败。
修复 ReflectionParameter 类型解析异常
PHP 8.5 中 ReflectionParameter::getType() 返回 ReflectionNamedType 实例更严格，而 Yii 2.0.49 的 DI 容器 build() 方法在遇到无类型声明参数（如 function foo($x)）时，会因无法处理新返回值而抛 TypeError。
第一步：定位问题函数
全局搜索项目中形如 function xxx($param) 且无类型提示的函数定义，尤其关注控制器 action 方法、事件回调、匿名函数。
第二步：补全类型声明
将 function handle($data) 改为 function handle(mixed $data)；若确定为字符串，写 string $data；数组统一用 array $data。不接受 void、null 等模糊类型占位。
第三步：验证容器行为
在任意控制器中临时添加：$container = \Yii::$app->getContainer();<br>var_dump($container->build('App\Service\YourService'));
若仍报错，说明该 Service 构造函数参数未补全类型。
规避 foreach 遍历 null 导致的致命错误
PHP 8.5 将 foreach(null) 从 warning 升级为 Fatal error，而 Yii 2.0.49 中部分模板渲染逻辑（如 GridView 数据源为空时）未做防御性判空，直接传入 null 给 foreach。
打开 vendor/yiisoft/yii2/widgets/ListView.php，找到 renderItems() 方法内类似 foreach ($this->dataProvider->getModels() as $model) 的语句。
在 foreach 前插入判空逻辑：
if (!is_array($this->dataProvider->getModels())) { return ''; }
同理检查所有自定义 GridView、ListView 子类，以及视图中手写的 foreach 循环——只要循环变量来源是用户输入、API 返回或数据库查询结果，都必须前置 is_array() 或 is_iterable() 判定。
注意：不要用 empty() 替代，empty([]) 为 false 但 empty(null) 为 true，无法区分空数组与 null，会导致逻辑跳过。
清除已知高危反序列化入口
Yii 2.0.49 已修复 BatchQueryResult::__destruct() 漏洞，但 vendor 中残留的旧版扩展（如 codeception 4.1.x、fzaninotto/faker 1.9.x）仍含 RunProcess、UnicodeString 等可触发反序列化的类，攻击者可通过日志文件、缓存文件注入恶意 payload。
方法一：升级关键扩展
执行：
composer update codeception/codeception fzaninotto/faker --with-dependencies
确保 codeception ≥ 5.0.0（移除 RunProcess）、faker ≥ 1.23.0（修复 Generator::__call 任意方法调用）。
方法二：禁用危险类自动加载
在 composer.json 的 autoload → exclude-from-classmap 中添加：
"vendor/codeception/codeception/ext/RunProcess.php",
"vendor/fzaninotto/faker/src/Faker/Generator.php"
然后运行 composer dump-autoload。
方法三：运行时拦截（最后一道防线）
在 web/index.php 开头添加：
ini_set('unserialize_callback_func', 'my_unserialize_callback');
function my_unserialize_callback($class) { if (in_array($class, ['Codeception\Extension\RunProcess', 'Faker\Generator'])) { throw new \Exception('Forbidden class deserialization'); } }
