spring三级缓存不解决构造器注入循环依赖，因其要求实例化时即获得完整依赖对象，无法提前暴露半成品；仅支持单例bean的字段或setter注入，通过singletonfactories→earlysingletonobjects→singletonobjects严格时序协作实现解耦。
Spring 三级缓存机制 **不解决构造器注入的循环依赖**，无论业务模型多复杂，只要存在 @Autowired 在构造器上且形成闭环，就会抛 BeanCurrentlyInCreationException。它只对单例 Bean 的字段注入 / setter 注入生效。
为什么构造器循环依赖一定失败？
构造器注入要求：实例化 A 的同时必须拿到 B 的完整实例；而 B 的构造器又要求 A 的完整实例 —— 二者互为前提，无法“提前暴露半成品”。三级缓存中的 singletonFactories 存的是 ObjectFactory，但构造阶段连对象都还没 new 出来，根本无法注册工厂。
- 构造器注入发生在 Bean 实例化（
new）阶段，早于任何缓存写入时机 -
singletonFactories只在实例化完成、属性填充前才被写入，构造器场景跳过了这个窗口 - 哪怕你手动加
@Lazy，也仅延迟 B 的创建时机，无法绕过构造器参数必须非 null 的校验
字段注入循环依赖能走通的关键路径
以 A 和 B 字段注入为例，三级缓存协作的核心在于“错开完整生命周期”：
- A 实例化后（
new A()），立刻将() -> A工厂塞进singletonFactories - A 填充属性时发现依赖 B，转而创建 B
- B 实例化后也注册工厂；填充属性时发现依赖 A，此时从
singletonFactories拿出工厂，调用getObject()得到早期 A 对象，并移入earlySingletonObjects - B 完成初始化，放入
singletonObjects；A 继续填充，从一级缓存取到已就绪的 B
整个过程依赖三个缓存的严格时序：singletonFactories → earlySingletonObjects → singletonObjects，缺一不可。
真实项目中容易踩的坑
你以为加了 @Lazy 就万事大吉？不一定。这些情况会让三级缓存失效：
- Bean 作用域是
@Scope("prototype")：原型 Bean 不进任何一级缓存，singletonFactories根本不参与 - A 或 B 被 AOP 代理（如
@Transactional）：代理对象生成时机可能晚于早期引用获取点，导致注入的是原始对象而非代理，引发事务/切面失效 - 使用
ApplicationContext.getBean(Class)手动触发依赖：绕过 Spring 自动装配流程，三级缓存逻辑不会被触发 - Spring Boot 2.6+ 默认禁用循环依赖：需显式配置
spring.main.allow-circular-references=true，否则直接启动失败
真正复杂的业务模型里，循环依赖往往不是技术问题，而是设计信号 —— 当你反复琢磨怎么让三级缓存“多撑一会儿”，大概率该拆接口、引入事件或重构领域边界了。缓存只是兜底，不是解耦的替代品。
