优先用构造函数注入。它语义清晰、类型安全、IDE支持好，能天然规避属性未初始化导致的NullReferenceException；@Inject注解注入仅适用于延迟初始化或动态代理等特定场景。
构造函数注入 vs @Inject 注解注入，选哪个？
优先用构造函数注入。它语义清晰、类型安全、IDE 支持好，且能天然规避属性未初始化导致的 NullReferenceException 类问题。
@Inject 注解注入只应在特定场景下使用：比如需要延迟初始化（如循环依赖）、或类本身被框架动态代理（如 AOP 切面目标类），而你又无法修改其构造签名。
- 构造函数注入要求参数类型明确，Hyperf 会自动解析并注入对应实例；若类型模糊（如多个实现注册了同一接口），会抛出
ContainerException -
@Inject默认不校验属性是否可写，如果属性是private但没加#[Inject]，运行时不会报错，但值为null—— 这是常见静默失败点 - PHP 8.2+ 的只读属性（
readonly）不能被@Inject修改，必须走构造函数
dependencies.php 中接口绑定的写法陷阱
配置文件里写错键名或类名，Hyperf 不会立刻报错，而是等到真正需要该服务时才失败，错误堆栈深、定位难。
正确写法必须严格匹配接口全限定名和实现类全限定名，且注意命名空间末尾是否有反斜杠：
- ✅ 正确：
UserServiceInterface::class => UserService::class - ❌ 错误：
'App\Service\UserServiceInterface' => 'App\Service\UserService'（字符串路径不被推荐，且易漏转义） - ❌ 错误：
UserServiceInterface::class => 'UserService'（右边不是完整类名，容器找不到） - 绑定抽象类时，右边必须是具体可实例化的子类，不能是另一个抽象类或接口
AOP 切面中依赖注入失效的典型原因
切面类（Aspect）本身支持依赖注入，但很多人忽略了一个关键前提：切面类必须被容器管理，即它得是一个“服务”，而不是普通 PHP 类。
如果你把切面定义成 class LogAspect 并直接 new 出来，它的 @Inject 属性永远是 null。
- ✅ 正确做法：在
dependencies.php中显式绑定切面类，或确保它被注解扫描到（如加#[Aspect]且所在目录已配置为注解扫描路径） - 切面方法（
process）的参数注入只支持ProceedingJoinPoint和容器中已注册的服务，不支持任意类型自动注入 - 若切面需访问请求上下文（如
RequestInterface），不能直接注入到切面属性，应通过JoinPoint获取，否则可能跨协程污染
可选依赖（?UserService）的实际约束
声明可选依赖确实能避免容器找不到服务时报错，但它不是“万能兜底”——它只解决“注入阶段”的缺失，不解决后续业务逻辑的空指针风险。
尤其要注意：Hyperf 1.1+ 支持 ?Type，但不支持 UnionType 如 UserSerivce|Null，后者会被当成联合类型解析失败。
- ✅ 可用：
public function __construct(?UserService $service) - ❌ 报错：
public function __construct(UserService|null $service)（PHP 8.0+ 联合类型语法，Hyperf DI 尚未完全兼容） - 即使用了可选依赖，调用前仍需判空，否则
$service->xxx()会触发致命错误 - 测试环境下若未注册该服务，可选依赖为
null是预期行为；生产环境建议配合健康检查主动告警，而非静默容忍
注解扫描和依赖注入高度耦合，但两者生效时机不同：注解在编译期扫描生成元数据，DI 在运行时按需解析。任何改动都需确认是否触发了注解缓存重建（php bin/hyperf.php gen:scan），否则新注解可能被忽略。
