它解决的是“硬编码依赖导致改一处、动全身”的维护问题：控制器中new UserService()会引发测试难、替换难、依赖嵌套深、生命周期失控等问题；构造函数注入是容器接管的前提，必须明确声明依赖并按序传参，且仅在Application实例化时生效。
它解决的是“硬编码依赖导致改一处、动全身”的实际维护问题。
控制器里 new UserService() 为什么很快会失控
当你在 SiteController 的 actionLogin() 里写 new UserService()，看似简单，但很快就会遇到这些情况：
- 测试时没法替换成模拟服务（
MockUserService），只能连真实数据库跑 - 换用 LDAP 登录时，得打开所有控制器文件，逐个把
new UserService()改成new LdapUserService() - 如果
UserService自己又依赖MailService和LogService，每次 new 都得手动传参、层层嵌套 - 多个控制器重复 new 同一个服务，无法统一控制生命周期（比如想让它全局单例）
构造函数注入不是语法糖，是容器能接管的前提
Yii2 的 yii\di\Container 不会自动扫描你写了多少个 new，它只响应明确声明的依赖。所以必须让类主动“说清楚”自己需要什么：
- 控制器构造函数参数里写
UserService $userService，等于告诉容器：“我需要这个服务” - 容器看到类型提示，就去查配置——有没有为
UserService注册过定义？有没有设置为单例？依赖的DbConnection是否已注册？ - 没注册就报错
Invalid Configuration – yii\base\InvalidConfigException，而不是运行时才发现Call to a member function login() on null
BaseController 继承写法里那行 parent::__construct() 不能乱放
很多人在自定义基类时把 $config 放前面，结果容器直接抛出 Missing required parameter。关键点就在这儿：
- Yii2 控制器父类
yii\base\Controller::__construct()只认三个固定参数：$id、$module、$config - 你加的
UserService $userService是额外依赖，必须放在$config之前，否则容器解析参数时会把$userService当作$config，把$config当作多余参数丢弃 -
parent::__construct($id, $module, $config)必须最后调用——因为父类初始化逻辑（比如设置$this->id）依赖这三个值，早调用会出错
真正容易被忽略的，不是“怎么写注入”，而是“容器什么时候开始介入”。它只在 Application 实例化控制器时才触发；如果你手动 new SiteController()，哪怕构造函数写对了，DI 也完全不生效。
