应优先改用构造器注入以提前暴露循环依赖；若必须用字段或setter注入，确保Bean为单例并避免@PostConstruct中触发其他Bean初始化；业务层隐式循环需通过事件解耦或ThreadLocal防护。
Spring里@Autowired报BeanCurrentlyInCreationException怎么办
这是循环依赖最典型的报错，说明两个或多个Bean在初始化过程中互相等待对方完成。Spring默认只对单例Bean做三级缓存支持循环依赖，且仅限于**构造器注入以外的场景**。
常见错误现象：@Autowired字段或@PostConstruct方法里又去调用另一个正在创建中的Bean；或者A依赖B，B依赖C，C又依赖A，形成环路。
- 优先改用构造器注入——它更清晰、不可变，也能提前暴露循环依赖（Spring会在启动时报
UnsatisfiedDependencyException，而不是运行时卡死） - 如果必须用setter/字段注入，确保所有参与循环的Bean都是
@Scope("singleton")（默认就是），否则二级缓存不生效 - 避免在
@PostConstruct中触发其他Bean的懒加载或代理初始化，比如调用applicationContext.getBean(X.class) - 检查是否误用了
@Lazy：它只延迟Bean创建，不解决依赖环；反而可能让问题更隐蔽
接口回调设计时，如何切断「Service A → Listener → Service A」这类隐式循环
这种不是Spring容器报错的循环，而是业务逻辑层的调用闭环。比如订单Service发事件，监听器又调用同一Service更新状态，结果事务没提交就再次进入同一方法。
使用场景：事件驱动架构、领域事件、审计日志、状态机流转。
立即学习“Java免费学习笔记（深入）”；
- 监听器里不要直接调用原Service，改用
ApplicationEventPublisher再发新事件，由独立的Handler处理（解耦+异步） - 如果必须同步调用，加一层门面（Facade）或委托类，明确标注“非事务性”或“仅用于回调”，并在Javadoc里写清调用约束
- 用ThreadLocal临时标记当前是否处于回调上下文，
if (inCallback.get()) return;是简单但有效的防护 - 注意Spring AOP代理失效场景：Listener是普通类而非Spring Bean，或回调走的是this.method()而非代理对象调用
用ObjectProvider或Provider延迟获取Bean真能破环？
能，但只适用于“需要时才取、且不立即初始化”的场景。它把依赖解析推迟到get()那一刻，绕过Spring启动时的依赖图校验。
参数差异：ObjectProvider<t></t>比Provider<t></t>多getIfAvailable()、stream()等安全方法，推荐前者。
- 适合用在可选依赖、条件化逻辑中，比如“有缓存Client就走缓存，没有就跳过”
- 不能滥用：如果每次
get()都新建Bean（如prototype作用域），会破坏单例语义；若目标Bean本身有复杂初始化逻辑，延迟也解决不了根本环 - 性能影响小，但会让依赖关系更难追踪——IDE和
spring-boot-starter-actuator的/beans端点看不到这个引用 - 示例：
private final ObjectProvider<retryservice> retryService;</retryservice>，构造器里接收，在真正要重试时才retryService.get().execute(...)
为什么把一个Bean拆成接口+实现类，有时反而加剧循环依赖
因为接口本身不参与依赖解析，但实现类仍可能被多个地方强引用。更关键的是，开发者常误以为“面向接口编程=自动解耦”，结果接口定义里塞了太多跨域方法，导致实现类不得不同时持有多个高耦合组件。
容易踩的坑：
- 接口方法签名暴露了不该暴露的依赖细节，比如
updateOrderAndNotifyUser(Order order, UserService userService)——这等于把UserService硬编码进契约 - 多个实现类共享同一接口，但各自依赖不同子系统，Spring容器在注入接口时无法区分该给谁，只能靠
@Qualifier补救，反而增加配置复杂度 - 用
@Primary强行指定默认实现，掩盖了实际依赖冲突，上线后某个模块行为异常却找不到源头 - 真正该做的，是按能力边界切分接口，比如
OrderStatusUpdater和UserNotifier分开定义，各自收敛依赖
循环依赖从来不是配置问题，而是职责划分模糊的信号。越想用技巧绕过，越说明那几个类本就不该彼此知道。拆接口没用，砍掉不该存在的调用链才有用。
