构造器注入循环依赖报错本质是创建时机冲突，双方卡在“等对方先建好”的死锁；优先重构治本，次选@Lazy打破闭环或降级为Setter/字段注入。
明确判断是否真需构造器注入
构造器注入本身是推荐实践，但前提是依赖关系是单向、可解耦的。如果两个 Service 必须互相持有对方的完整实例，大概率说明职责边界模糊。
检查这两个 Bean 是否真的需要彼此调用业务方法？还是仅为了触发某段逻辑？后者更适合用事件或回调解耦。
首选方案：用 @Lazy 打破初始化闭环
@Lazy 不是“偷懒”，而是让 Spring 为被标记的 Bean 创建一个临时代理对象，先满足构造入参，等真正调用时才去初始化真实实例。它不改变代码结构，见效快，且兼容 Spring Boot 2.6+ 默认禁用循环依赖的环境。
- 只加在构造器参数上（不能加在字段或 setter 上），例如：
public OrderService(@Lazy PayService payService) - 确保被 @Lazy 标记的 Bean 本身不是 prototype 或其他非单例作用域，否则代理行为不可靠
- 注意：首次调用该 Bean 方法时会触发完整初始化，若此时另一方尚未就绪，仍可能抛 NPE 或空指针——需配合合理调用顺序或初始化检查
次选方案：降级为 Setter 或字段注入
如果业务允许延迟注入（即对象实例化后、使用前再设依赖），可临时改为 @Autowired 字段或 setter 注入。Spring 的三级缓存机制能自然处理这种单例 + 非构造注入的循环。
- 字段注入最简：
@Autowired private BService bService; - Setter 注入更显式可控：
@Autowired public void setBService(BService bService) { this.bService = bService; } - ⚠️ 注意：此举放弃构造器注入的不可变性和测试友好性，仅建议过渡期使用
根治方案：拆分或引入中间层
真正可持续的做法是让循环“消失”。常见手法包括：
- 提取共用逻辑：A 和 B 都调用的某段流程，抽成独立的 CService，由 A、B 分别依赖 C，而非互赖
- 引入事件机制：A 完成操作后发布事件，B 订阅该事件并响应，解除直接引用
- 定义接口+策略分离：A 依赖某个接口，B 实现该接口；但 B 不反向依赖 A，而是由第三方协调（如工厂或上下文）
