yii 2.0 中 yii::$app 是服务定位器而非 di 容器，真正 di 需用 yii\di\container 并手动 set() 绑定接口；yii::$container 与 yii::$app->container 默认指向同一实例，但前者是全局 di 操作入口，后者仅限应用内作用域。
Yii 框架的依赖注入容器不是“额外加装”的模块，而是 Application 类原生内置的 yii\di\Container 实例，它从应用启动那一刻起就在工作——你调用 \Yii::$app->db、\Yii::$app->cache，背后全是它在解析依赖、缓存单例、递归构造对象。
怎么确认容器已经生效？看 \Yii::$container 和 \Yii::$app 的关系
\Yii::$container 是全局 DI 容器实例，\Yii::$app（即 Application）内部也持有一个 $container 属性，二者默认指向同一个对象。但注意：\Yii::$app->container 是服务定位器（Service Locator）风格的访问方式，而 \Yii::$container 是直接操作 DI 容器本身。
- 修改
\Yii::$container会影响所有后续通过容器创建的对象（包括\Yii::$app内部组件的重建） - 修改
\Yii::$app->container只影响该 Application 实例范围内的容器行为（比如多应用场景下隔离配置） - 除非你明确要覆盖整个应用生命周期的容器行为，否则优先用
\Yii::$container->set()而非改写\Yii::$app->container
接口绑定必须用 set()，不能只靠配置文件
应用配置里的 components 部分只能注册具名组件（如 'db'、'myService'），它不支持「接口 → 实现类」这种抽象绑定。真正实现解耦的关键一步，得手动调用容器的 set()：
\Yii::$container->set('app\interfaces\PaymentGateway', 'app\services\AlipayService');
- 这个绑定意味着：只要某个类构造函数声明了
PaymentGateway $gateway参数，容器就能自动注入AlipayService实例 - 若之后换成微信支付，只需改这一行，无需动任何业务类代码
- 注意：接口名必须是完整命名空间路径，且类必须可自动解析（无构造参数，或其参数也能被容器提供）
构造函数注入失败？先检查参数类型和容器能否解析
常见报错 ReflectionException: Class xxx does not exist 或 Cannot resolve dependency，往往不是写法错，而是容器卡在某一层依赖上：
- 构造函数中用了具体类（如
SomeHelper $helper），但该类没在容器中注册、也没定义默认实现，容器就无法实例化 - 参数类型是 interface 或 abstract class，但没提前用
set()绑定，容器找不到实现类 - 参数带默认值（如
array $options = []）时，容器会跳过它；但若类型提示是string $name且没默认值，容器就必须提供，否则抛异常 - 避免在构造函数里做 heavy 初始化（如连接 DB、读文件），这会让容器构建变慢且难以 mock 测试
循环依赖不是配置问题，是设计信号
当容器报 Circular reference to "xxx" detected，别急着加 setSingleton() 或换 setter 注入——这说明两个类在构造阶段互相需要对方，本质是职责没划清。
- 典型场景：A 类在构造函数里要 B 实例，B 类构造函数里又要 A 实例
- setter 注入只是绕过报错，没解决耦合问题；更稳妥的是提取公共逻辑到第三个服务 C，让 A 和 B 都依赖 C
- 如果真无法拆分（如事件监听器与事件分发器），可用
setSingleton()+ 延迟初始化（把实际依赖逻辑移到方法里，而非构造函数） - 容器不会自动破循环，它只是诚实告诉你：“我没法无限套娃”
真正难的不是写 set() 或配 components，而是判断哪些依赖该进容器、哪些该由调用方传入——接口绑定容易，但接口定义是否合理，得看业务边界划得够不够干净。
