@inject(required=false) 仅在di容器无法找到指定名称的接口实现时注入null，适用于日志上报等可选能力，需配合空值判断，不可用于核心依赖，误用易导致运行时调用null对象错误。
@Inject(required=false) 什么时候该设为 false
当某个依赖在某些运行路径下可能根本用不到，或者它本身是可选能力（比如日志上报、异步通知、降级开关），又不想让容器启动失败或构造失败时，才考虑设 required=false。它不是“兜底写法”，而是明确表达“这个依赖缺失是可以接受的”。
常见误用是：一看到类里有可选服务，就无脑加 required=false，结果后续调用 $this->optionalService->send() 时直接报 Call to a member function send() on null —— 这个错误比容器启动报错更难定位。
- 必须配合空值判断，不能裸用：
if ($this->optionalService) { $this->optionalService->send(); } - 不推荐用于核心业务流程中的关键依赖（如数据库连接、主配置对象）
- 如果只是想“避免启动失败”，更稳妥的做法是注册一个空实现（Null Object），而不是注入
null
required=false 的实际生效条件
required=false 只在 DI 容器尝试解析该属性类型时起作用。它不会跳过类型检查，也不会绕过构造函数参数注入 —— 它只影响属性注入阶段对“找不到对应定义”的容忍度。
也就是说，以下两种情况它都管不了：
- 该属性用了
@var SomeInterface，但SomeInterface在dependencies.php中完全没注册任何实现 → 即使required=false，仍会抛ContainerException - 该属性类型是具体类（如
@var CacheManager），但类存在且无构造依赖，required=false实际无效（因为一定能实例化）
真正触发 required=false 生效的典型场景是：接口已注册，但你传的 name 错了，或注册的是 Interface@aliyun 却没配 name="aliyun"，此时容器找不到匹配项，才会安静地注入 null。
required=false 和 @Inject(name=...) 能一起用吗
能，但意义不大。因为 name 参数的作用就是精准定位某一个绑定，一旦指定了 name，容器就会严格按 Interface@name 去找；找不到就是找不到，required=false 才会生效。
所以如果你写了：
#[Inject(name: 'aliyun', required: false)] private UserServiceInterface $userService;
那它只会在 dependencies.php 里缺 UserServiceInterface@aliyun 这一项时注入 null，而不会 fallback 到其他 name（比如 @qcloud）或默认实现。
容易踩的坑：
- 注册了
UserServiceInterface@Aliyun（大写 A），却写name='aliyun'→ 匹配失败，required=false生效，注入null - 注册了
UserServiceInterface@aliyun，但对应类AliyunUserService的构造函数依赖未注册的LoggerInterface→ 容器抛的是构造失败异常，不是“找不到定义”，required=false不起作用
替代方案：比 required=false 更清晰的写法
很多情况下，用 required=false 是为了应对“环境差异”或“功能开关”，但代码可读性差。更推荐两种替代方式：
- 用
@Value("feature.async_notify")控制是否启用某逻辑，依赖本身仍设required=true，由业务层决定是否调用 - 在
dependencies.php中统一注册一个空实现：NullNotifier::class，然后绑定NotifierInterface@default => NullNotifier::class，这样所有地方都能安全调用，也不需要判空
真正需要 required=false 的场景其实很少——它不是容错机制，而是“声明式可选依赖”的语法糖，用之前得先确认：这个 null 真的能在所有调用点被安全处理。
