yii的setter注入是配置驱动而非自动反射，仅当配置中显式声明键名（如'apiurl'=>'xxx'）且存在对应public setapiurl()方法时才生效；@property仅为ide提示，不参与运行时注入。
Yii 里 setter 注入靠 set 方法名 + 配置数组，不是自动扫描
Yii 的属性注入（即 setter 注入）本质是“配置驱动”，不是靠反射自动调用所有 setXxx 方法。它只在你显式声明了属性绑定时才生效，比如在 components 配置里写 'class' => 'App\SomeService', 'someProp' => 'value' —— 这时框架才会尝试调用 setSomeProp()。
常见错误是以为只要写了 setApiUrl()，容器就会自动识别并注入；其实不会，必须在配置中明确给出键名 'apiUrl' => 'https://api.example.com'，且该键名要和方法名去掉 set、首字母小写后完全一致。
-
setCacheTime()对应配置项是'cacheTime' => 3600，不是'CacheTime'或'cache_time' - 如果类里只有
public $timeout;没有setTimeout()，配置'timeout' => 5不会触发 setter，而是直接赋值给 public 属性（不推荐） - setter 方法必须是 public，且参数类型不能太严格（如声明
string|null而配置传了''，可能触发类型报错）
注解注入（@property）只是 IDE 提示，Yii 官方不支持运行时注解解析
很多人看到 PHPDoc 里的 @property 就以为 Yii 能据此做依赖注入，其实不能。@property 在 Yii 中仅用于生成文档、辅助 IDE 补全，运行时不被容器读取，也不会触发任何注入行为。
真实场景中，如果你在 SomeService 类上写了 @property User $user，但没在配置里声明 'user' => ['class' => 'App\User']，那 $this->user 就是 null，不会自动实例化。
- 想让
@property“起作用”，得手动在init()里补上逻辑：$this->user = \Yii::$app->get('user'); - 第三方扩展如
yii2-annotation-injector可实现注解驱动注入，但它不是 Yii 内置能力，需额外引入、注册行为，且性能开销明显 - 注解写错格式（如漏掉
App\User全类名）会导致 IDE 误判，但不影响运行——因为根本没被读取
setter 注入 vs 构造函数注入：选哪个取决于生命周期和可变性
Setter 注入适合那些可能在对象创建后被重置、或需要根据上下文动态调整的依赖；构造函数注入则更利于表达“不可变依赖”和强制约束。
比如日志通道（LoggerInterface）通常用构造注入，确保每个实例都有 logger；而缓存前缀（cachePrefix）可能随请求变化，用 setter 更灵活。
- 构造注入需在
__construct()中声明参数，并在容器配置里用'class' => X, 'params' => [...]传入 - setter 注入不要求参数必填，缺失时 setter 不会被调用，属性保持默认值或 null —— 这既是便利也是隐患
- 混合使用时注意顺序：Yii 先执行构造函数，再按配置顺序调用 setter，所以别在
__construct()里依赖尚未被 setter 设置的属性
调试注入失败最有效的三步：看配置键、查方法签名、断点 BaseObject::configure()
注入没生效？别急着翻源码，先盯住这三点。Yii 的核心注入逻辑实际发生在 BaseObject::configure()，所有组件初始化都走这里。
典型现象是属性始终为 null 或默认值，但配置明明写了。这时候：
- 确认配置里的 key 名是否和
setXxx()方法名转换后完全一致（大小写、下划线、驼峰） - 检查
setXxx()是否返回$this（虽然不强制，但链式调用习惯会让部分中间件依赖这个） - 在
BaseObject::configure()开头加一行var_dump($config);，看实际传进来的数组长什么样 —— 常见原因是配置嵌套层级不对，比如把'components' => ['mySvc' => [...]]错写成'mySvc' => [...]
复杂点在于：setter 注入没有失败日志，出问题就是静默忽略。你得自己卡在 configure() 里看哪一步没匹配上，而不是等报错。
