yii 3 的依赖冲突本质是 composer 冲突，非框架层问题；其依赖通过 psr-11 容器显式声明注入，配置统一收口于 config/common.php，重复绑定或 php 版本低于 8.2 会立即报错，而非运行时隐性冲突。
Yii 3 的包依赖冲突和 Yii 2.0 的处理逻辑完全不同——不是“怎么解决冲突”，而是“根本不会出现传统意义上的 Maven 式依赖冲突”。原因在于：Yii 3 不再使用全局 ServiceLocator + 隐式组件注册机制，所有依赖都通过 PSR-11 容器显式声明、按需注入；而 Yii 2.0 的依赖管理仍基于松耦合的 ServiceLocator 和运行时动态解析，更容易因配置覆盖、类名冲突或版本混用引发隐性问题。
Yii 3 的依赖冲突本质是 Composer 冲突，不是框架层问题
Yii 3 本身不参与依赖解析，它完全交由 Composer 管理。所谓“Yii 3 包冲突”，实际是多个扩展包要求不同主版本 PHP 或互斥的底层库（如 psr/http-message、symfony/polyfill）导致的 Composer 安装失败。
- 典型报错：
Your requirements could not be resolved to an installable set of packages，说明 composer.lock 中存在无法满足的约束 - 关键检查点：确认所有包都兼容 PHP ≥8.2（Yii 3 硬性门槛），且没有同时 require
psr/http-message:^1.0和^2.0这类不兼容版本 - 解决方式：运行
composer update --with-all-dependencies强制刷新整条依赖链；或用composer prohibits vendor/package:version定位冲突源头
Yii 2.0 的“冲突”多源于运行时行为，而非安装阶段
Yii 2.0 没有强制 DI 容器，依赖靠 Yii::$app->get('db') 动态获取，这带来两类典型问题：
-
组件重注册覆盖：两个扩展都调用
$app->set('cache', [...])，后注册的会覆盖前一个，但无警告 -
类名/命名空间碰撞：比如自定义
yii\helpers\Html覆盖了框架原生类，PHP 7.2+ 后因Object成为保留字，yii\base\Object在低版本 Yii 2.0.x 中直接 fatal error - 排查手段：启用
debug模式查看组件初始化日志；检查config/bootstrap.php和模块 init() 中的 set() 调用顺序
配置方式差异决定冲突发生位置
Yii 2.0 允许在任意 config 文件里写 'components' => ['db' => [...]]，多处合并时易覆盖；Yii 3 把全部配置收口到 config/common.php，格式为键值对映射，容器启动时一次性绑定，不存在“合并逻辑”。
- Yii 2.0 示例：
'components' => ['log' => ['class' => 'yii\log\Logger']]可分散在 main.php、local.php、module.php 中 - Yii 3 示例：
LoggerInterface::class => ['class' => FileLogger::class]必须唯一声明，重复定义会触发 Fatal Error - 这意味着 Yii 3 的“冲突”在代码写完时就暴露（PHP 类型错误或容器绑定异常），而不是上线后才随机报错
迁移时最常踩的“伪冲突”陷阱
开发者常把 Yii 2.0 习惯带入 Yii 3，误以为是依赖冲突，实则是架构范式不匹配：
- 试图在控制器方法里调用
Yii::getContainer()->get()→ 报错Call to undefined method，本质是弃用 API，不是版本问题 - 沿用
Yii::createObject(['class' => ...])→ 报错Uncaught Error: Call to undefined function yii\di\is_callable()，根源是 PHP 版本低于 8.2，非依赖冲突 - 用 YAML/XML 配置文件 → Composer 安装成功但运行时报
Invalid config format，因为 Yii 3 只接受 PHP 数组格式
