构造器注入无法解决循环依赖，根本原因是其“对象创建即完整”的语义与spring生命周期机制冲突：构造器调用必须传入已就绪的实参，而循环场景下双方互为前提，无中间态可妥协；三级缓存（工厂、早期引用、成品）均无法介入构造阶段，故容器主动抛出beancurrentlyincreationexception以防御性保护。
构造器注入无法解决循环依赖，根本原因在于它的语义和 Spring 容器的生命周期机制不兼容——对象必须在构造完成时就持有所有不可变依赖，而循环场景下这个“所有依赖已就绪”的前提无法满足。
构造器注入要求对象创建即完整
Spring 在实例化一个 bean 时，构造器是第一步也是最关键的一步。如果类 A 的构造器需要 B，那 Spring 必须先拿到一个可用的 B 实例，才能调用 A(B b)；同理，B 的构造器又需要 A。两者互为前提，没有中间态可妥协。
这和 setter 或字段注入不同：后者允许先 new 出空壳对象，再逐步设值。构造器注入则没有“空壳”——它天生拒绝半成品。
三级缓存对构造器注入完全失效
Spring 的三级缓存（singletonFactories、earlySingletonObjects、singletonObjects）本质是为“延迟填充”服务的，但构造器参数必须是实参，不能是代理、工厂或占位符：
- 三级缓存（工厂）：只能返回对象实例，但构造器调用需要的是真实对象，不是 ObjectFactory
- 二级缓存（早期引用）：存放的是已实例化但未初始化的对象，适用于 setter 注入；构造器注入发生在实例化阶段之前，此时连“早期引用”都还不存在
- 一级缓存（成品 bean）：只有初始化完成后才放入，而循环中谁也走不到那一步
异常表现就是容器主动拒绝启动
Spring 不会尝试硬解这个死锁，而是直接抛出 BeanCurrentlyInCreationException，日志里明确提示 “requested bean is currently in creation”。这不是 bug，是设计上的防御性保护——避免运行时出现更隐蔽的问题，比如部分初始化、AOP 代理错乱或状态不一致。
这不是技术限制，而是建模信号
两个 service 通过构造器相互持有，往往说明职责边界不清。比如订单服务直接依赖库存服务，而不是通过领域事件、策略接口或应用层协调。这种耦合会让测试困难、扩展受限、演进僵硬。真正治本的方式是重构关系，而非绕过容器约束。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
