它解决的是“硬编码依赖导致改一处、动全身”的维护问题：控制器中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，它只响应明确声明的依赖。所以必须让类主动“说清楚”自己需要什么：

Yii Framework 2.0.51

Yii Framework 2.0.51 官方 Basic 应用模板，适合旧项目兼容、升级验证和开发测试。

下载

• 控制器构造函数参数里写 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 也完全不生效。