hyperf 的 di 容器是框架基石，构造函数注入需容器创建实例、依赖类符合 psr-4 且接口须绑定实现；@inject 仅支持 private 属性注入并需 @var 类型声明；接口绑定适用于静态映射，工厂注入用于动态逻辑；生命周期须显式配置 scope，否则协程间数据串。
Hyperf 的依赖注入容器不是“可选功能”，而是整个框架运行的基石——没它，Controller、Service、Middleware 都无法被自动创建和注入，#[Inject] 会直接失效，dependencies.php 配置也毫无作用。
构造函数注入为什么有时不生效？
常见现象：写了 public function __construct(UserService $userService)，但运行时报错 Typed property must not be accessed before initialization 或 Cannot resolve UserService。
- 类必须由 DI 容器创建——手动
new UserController()绕过容器，构造函数参数不会被解析，注入自然失败 - 依赖类本身也要能被容器识别：确保
UserService类有完整命名空间、文件路径符合 PSR-4 规范（如app/Service/UserService.php），且未被composer dump-autoload排除 - 若依赖是接口类型（如
UserServiceInterface），必须在config/autoload/dependencies.php中明确绑定实现类，否则容器不知道该注入谁
@Inject 注解注入的边界在哪？
#[Inject] 看似简单，但只对容器管理的类生效，且仅支持属性注入（不支持方法或参数级注入），也不支持 PHP 8.0 以下版本。
- 必须配合
@var使用，类型声明不能省：#[Inject] private UserService $userService;✅，#[Inject] private $userService;❌ - 属性不能是
public，否则注入会被跳过；protected在某些场景下也可能失效，推荐统一用private - 注解只在类被容器反射加载时触发——比如通过路由访问 Controller，或通过
ApplicationContext::get()获取实例；直接 new 实例时注解完全不执行
接口绑定与工厂注入怎么选？
当需要动态决定注入哪个实现，或构造逻辑复杂（如需读配置、连接外部服务）时，不能只靠类名直连。
- 接口绑定适合静态映射：
UserServiceInterface::class => UserService::class，轻量、高效，适用于绝大多数场景 - 工厂注入用于带条件或副作用的初始化：
UserServiceInterface::class => UserServiceFactory::class，工厂类必须实现__invoke(ContainerInterface $container)方法，返回具体实例 - 注意工厂本身也是被容器管理的——如果工厂内部又依赖其他服务，这些依赖会自动注入，无需手动 new
真正容易被忽略的是生命周期控制：默认所有类都是单例（Singleton），但像 Request 相关对象（如 RequestInterface）必须是请求级单例（Scoped），否则协程间数据会串。这个不是靠写法决定的，而是在 config/autoload/dependencies.php 中显式配置 scope，漏配会导致静默 bug。
