hyperf 中可选依赖由 di 容器原生支持，通过 nullable 类型声明（如 ?interface）或 #[inject(required: false)] 实现，参数缺失时注入 null 而非报错，需配合正确命名空间、清缓存及业务逻辑覆盖。
Hyperf 中可选依赖不是靠“手动判空”或“try-catch”硬扛出来的，而是由 DI 容器原生支持的明确语义：参数缺失时不报错，直接注入 null。关键在于写法和版本约束。
构造函数参数声明为 nullable
这是最直接、最推荐的方式，适用于你明确知道某个依赖可能不存在的场景（比如某功能模块可插拔）。
- 必须使用 PHP 7.1+ 的类型声明语法，参数类型后加
?string、?UserServiceInterface这类 nullable 类型 - Hyperf 1.1.0+ 才支持该行为；旧版本即使写了
?UserServiceInterface，容器仍会尝试解析并抛出ClassNotFoundException - 接口绑定未配置时，容器不会 fallback 到实现类，而是严格按类型提示找注册项；没找到就塞
null
示例：
public function __construct(private ?App\Contracts\PaymentGatewayInterface $gateway) { }如果 PaymentGatewayInterface::class 在 dependencies.php 中没绑定，$gateway 就是 null，不会报错。
@Inject 注解配合 required=false
当你用注解注入且需要更细粒度控制（比如只在某些环境启用），required 参数比类型声明更灵活。
- 必须显式写
#[Inject(required: false)]，不能只写#[Inject]—— 默认值是true，不写等于强制要求 - 属性类型仍需声明为 nullable（如
private ?UserServiceInterface $userService;），否则 PHP 会在赋值null时触发类型错误 - 该方式对
new出来的对象也生效，不依赖容器创建流程
示例：
#[Inject(required: false)]<br>private ?App\Contracts\MetricsReporterInterface $reporter;即使
MetricsReporterInterface 没在容器中注册，也不会中断实例化。
容易踩的三个坑
可选依赖看着简单，但实际项目里最容易翻车的地方很集中：
- 忘记清缓存：改完
dependencies.php或注解后，不执行php bin/hyperf.php cache:clear，容器仍用旧定义，required=false可能被忽略 - 类型提示写错命名空间：比如写成
private ?UserServiceInterface $service;而不是private ?App\Contracts\UserServiceInterface $service;，PHP 解析为当前命名空间下的类，容器根本找不到这个“假接口”，直接报Cannot instantiate interface - 误以为
required=false能绕过循环依赖：它只解决“找不到依赖”的问题，不解决“ServiceA 构造器要 ServiceB，ServiceB 构造器又要 ServiceA”这种死锁；这种情况必须用@Lazy+ setter 或重构职责
真正需要可选依赖时，往往意味着系统设计上存在条件性能力；别只盯着怎么让注入不崩，先确认那个 null 后的业务分支是否真的被覆盖到了。
