Hyperf构造函数循环依赖报错典型现象是启动时抛出“Cannot resolve circular reference”异常，本质是DI容器在构建对象图时检测到A↔B闭环而中止实例化；必须用LazyProxy配合接口实现延迟解析依赖，而非setter或属性注入绕过。
Hyperf里构造函数循环依赖报错的典型现象
启动服务时直接抛出 RuntimeException，错误信息类似："Cannot resolve circular reference for service 'App\Service\AService'"。这不是 PHP 语法错误，而是 Hyperf 的 DI 容器在构建对象图时检测到 A 依赖 B、B 又依赖 A 的闭环，主动中止了实例化。
为什么不能靠 setter 或属性注入绕过？
Hyperf 默认只对构造函数参数做自动注入，@Inject 注解写在属性或 setter 上不会被容器自动调用——除非你手动触发，但那样就失去了依赖自动管理的意义。更关键的是，即使写了 setter，如果构造函数里已经强制要求另一个服务实例，循环依然存在。
真正能破局的，是让其中一端不“立刻要实例”，而是“需要时再取”。这就轮到 LazyProxy 出场：
-
LazyProxy不是延迟创建对象，而是延迟解析依赖关系；它返回一个代理对象，首次调用方法时才去容器里 get 实例 - 必须配合接口使用（Hyperf 要靠接口名做代理生成），且该接口需被容器管理（即有
@Inject或已定义为 singleton） - 不能用于 final 类或没有接口的类，否则代理生成失败，运行时报
Class not found
用 LazyProxy 解决 A ↔ B 循环的具体步骤
假设 AService 依赖 BService，BService 又依赖 AService：
第一步：提取公共接口，比如 IAService 和 IBService，各自声明对应方法；
第二步：让两个类实现对应接口，并在容器配置中注册为单例（通常用 @Bean 注解即可）；
第三步：在构造函数中，把原本的类类型提示，改成接口类型，并加上 @Inject + @Value("lazy")：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
class BService implements IBService
{
public function __construct(
#[Inject, Value("lazy")] protected IAService $aService
) {
}
}
注意：@Value("lazy") 是关键，缺了它还是立即解析；$aService 看似是 IAService，实际是 Hyperf\Di\Proxy\LazyProxy 的子类实例。
容易忽略的兼容性与调试细节
LazyProxy 生成的代理类会拦截所有 public 方法调用，但无法代理魔术方法（如 __get、__call），所以别在被代理的接口里定义这些；
IDE 可能无法识别代理对象的方法提示，建议在 PHPDoc 中补全类型注解：/** @var IAService $this->aService */；
若启用 opcache.enable = 1 且未配置 opcache.save_comments = 1，代理类生成会失败，报 ReflectionException: Class does not exist —— 这个错误和循环依赖无关，但现象相似，得先排查 opcache 配置。
代理本身有微小开销，高频调用场景下可考虑用事件或回调解耦，而不是硬扛循环依赖。
