Hyperf 的 DI 本质是 hyperf/di 实现的 PSR-11 容器，核心问题在于类解析时机、实例创建策略及循环依赖导致的协程栈溢出；构造器注入无三级缓存，易触发无限递归；@Lazy 必须与 @Inject 同用在属性上才生效，用于延迟依赖解析而非初始化；接口绑定适用于一对一实现，工厂注入支持运行时参数与资源复用；隐式双向调用会引发协程环境下资源竞争与内存泄漏。
Hyperf 的依赖注入（DI）不是“是什么”的概念题，而是你启动服务时容器卡死、Maximum function nesting level 报错、或者改个类就 ClassNotFoundException 的实际问题源头。它本质是 hyperf/di 组件实现的 PSR-11 容器，但真正影响你每天开发的，是它怎么解析类、何时创建实例、以及哪些写法会让协程栈直接爆掉。
构造函数注入为什么一用就循环依赖？
Hyperf 默认走构造器注入，而它的容器没有 Spring 那样的三级缓存机制。一旦 ServiceA 构造器依赖 ServiceB，ServiceB 构造器又依赖 ServiceA，容器就会陷入无限递归解析：
- 尝试 new ServiceA → 需要 ServiceB → 尝试 new ServiceB → 需要 ServiceA → …
- 最终触发
Fatal error: Maximum function nesting level of '256' reached - 不是配置漏了，是依赖图本身无法收敛
- 只改一个类用 setter，另一个还用构造器？照样失败——容器必须先完整构建被注入方
@Inject 和 @Lazy 必须一起用才有效
@Inject 单独加在属性上，容器会在构建当前类时立刻尝试解析并实例化依赖；而 @Lazy 的作用不是“延迟初始化”，而是“延迟依赖解析”——它让容器生成一个代理对象占位，直到第一次调用该属性的方法时才真正去构建目标实例。
-
@Lazy必须写在属性声明行，加在构造器参数里无效 - 只对
@Inject属性生效，对 setter 方法不生效 - 高频请求中大量
@LazyBean 集中触发初始化，可能引发瞬时 CPU 尖峰和协程阻塞 - 代理对象本身有开销，别滥用在简单值对象或无状态工具类上
接口绑定和工厂注入的实际差异在哪？
在 config/autoload/dependencies.php 里写 UserServiceInterface::class => UserService::class，这是接口绑定；而工厂注入是返回一个 callable，用于控制复杂对象的创建时机与上下文。
- 接口绑定适用于“一个接口对应一个实现”的场景，简单直接
- 工厂注入适合需要运行时参数（如租户 ID）、连接池选择、或需复用已有资源（如共享 Redis 连接）的情况
- 工厂返回的对象默认是 prototype（每次 get 都新建），若需单例，得显式调用
$container->get(YourFactory::class)->create()并自行管理生命周期 - 工厂函数里不要做耗时操作（如 DB 查询），否则会拖慢整个容器启动
UserService 里悄悄调了 OrderService，而 OrderService 又反向查了 UserCache，这种隐式双向调用在协程长生命周期下会放大成资源竞争或内存泄漏——这时候再加 @Lazy 也救不了设计本身。 
