Spring三级缓存仅支持单例Bean的属性/字段注入循环依赖，不支持构造器注入、多例（prototype）及request/session作用域循环依赖，因构造器注入在实例化前即需完整依赖，无法进入缓存注册流程。

Spring 的三级缓存机制只对单例（singleton）Bean 的**属性注入型循环依赖**有效，不解决构造器注入循环、多例（prototype）循环，也不适用于字段未初始化就调用的场景。

为什么 constructor 注入会直接失败

构造器注入要求所有依赖在实例化前就“完全可用”，而循环双方都卡在彼此未完成构造的阶段。Spring 连一级缓存都进不去，更不会走到三级缓存逻辑。

• getBean("A") → 实例化 A → 需要 B → 调用 getBean("B")
• getBean("B") → 实例化 B → 需要 A → 再次调用 getBean("A")，此时 A 尚未放入任何缓存（连三级缓存都没来得及注册），抛出 BeanCurrentlyInCreationException

所以只要存在任一环是构造器注入，三级缓存就彻底失效 —— 不是它“没起作用”，而是根本没机会触发。

singletonFactories 是关键，但只在特定时机注册

三级缓存真正起作用的前提是：Spring 必须在 A 刚完成实例化（new A()）、尚未填充属性时，就把一个 ObjectFactory 放进 singletonFactories。这个动作发生在 createBeanInstance 之后、populateBean 之前。

• 只有 singleton Bean 才会走这个流程；prototype 每次都新建，跳过缓存注册
• 如果 A 类上加了 @Lazy，首次 getBean("A") 不会提前暴露，singletonFactories 不会被填充，B 就取不到早期引用
• ObjectFactory.getObject() 返回的是原始对象（非代理），但如果 A 后续需要 AOP 代理，这个早期暴露的对象可能和最终代理不一致 —— Spring 会在代理生成后覆盖二级缓存中的原始对象

常见误判：以为加了 @Autowired 就自动支持循环

实际是否能解，取决于两个 Bean 的创建顺序和注入方式组合。比如：

• A 使用 @Autowired private B b（field 注入），B 使用构造器注入 A → 失败（B 构造时 A 还没准备好）
• A 和 B 都用 field 或 setter 注入 → 成功（三级缓存可介入）
• A 是普通 Bean，B 是 @Async 或 @Transactional 增强 Bean → 可能成功，但要注意代理对象是否被正确替换进二级缓存

尤其注意：Lombok 的 @RequiredArgsConstructor 默认生成构造器注入，容易在无意中引入构造循环。

复杂模型下真正该做的不是“硬解”，而是识别边界

当业务模型出现 A→B→C→A 式长链循环，或混合了 @PostConstruct、事件监听、异步回调等行为时，三级缓存已无法兜底。此时强行保留循环，会导致：

• 单元测试难 mock（依赖链太深）
• 启动时序敏感（某个 Bean 初始化早于预期）
• 代理失效（如 @Scheduled 方法被注入到未代理对象中）

比“怎么让三级缓存生效”更重要的是：用 @Lazy 打断强依赖，或把共享逻辑抽成无状态工具类 / @Service，让双方都依赖第三方 —— 这些改动往往比调试缓存命中更可靠。