排查Requested bean is currently in creation异常（附相关代码）

嘿，这个报错我太熟了——这几乎100%是Spring循环依赖搞出来的问题。咱们先把原因掰扯清楚，再一步步解决它。

为什么会出现这个错误？ #

简单来说：当两个（或多个）Bean在初始化过程中互相“掐着脖子”——A创建时需要B，B创建时又需要A，Spring容器没办法按顺序完成它们的初始化，就会抛出这个“当前Bean正在创建中”的提示。

结合你贴的代码来看，虽然只展示了部分，但大概率是这几个组件形成了闭环：比如CheckUserDataRestController依赖UserSearchServiceImpl，而UserSearchServiceImpl（或者它依赖的AuthorizationService/UserRepository）又直接或间接依赖了CheckUserDataRestController；或者是UserSearchServiceImpl和AuthorizationService之间互相依赖。

怎么解决？ #

第一步：先精准定位循环链路 #

先把Spring的日志级别调到DEBUG，日志里会明确告诉你哪几个Bean形成了循环。比如在application.yml里这么配置：

logging:
  level:
    org.springframework.beans.factory: DEBUG

启动项目后，找包含Circular reference的日志条目，它会清晰列出循环的Bean链路，比如CheckUserDataRestController → UserSearchServiceImpl → AuthorizationService → CheckUserDataRestController。

第二步：根据循环场景选解决方案 #

场景1：Controller和Service互相依赖

这是设计上的问题——Controller是请求入口，不该被Service层依赖。你需要把Service里依赖Controller的逻辑抽出来，放到一个独立的组件（比如新的Service类、工具类）里，彻底打破循环。

场景2：Service之间互相依赖（比如UserSearchServiceImpl和AuthorizationService）

这里有几个实用方案：

• 用@Lazy延迟初始化：在其中一个Bean的依赖注入处加@Lazy，让Spring先创建当前Bean，另一个Bean在第一次被调用时再初始化。比如修改UserSearchServiceImpl的构造函数：

  @Autowired
  public UserSearchServiceImpl(UserRepository userRepository, @Lazy AuthorizationService authorizationService) {
      this.userRepository = userRepository;
      this.authorizationService = authorizationService;
  }
  

• 改用Setter注入代替构造器注入：Spring原生支持用Setter注入解决循环依赖（构造器注入是在Bean创建阶段就需要依赖，而Setter注入是Bean创建完成后再赋值）。比如把UserSearchServiceImpl的注入方式改成：

  @Service("userSearchService")
  public class UserSearchServiceImpl implements UserSearchService {
      private UserRepository userRepository;
      private AuthorizationService authorizationService;
  
      @Autowired
      public void setUserRepository(UserRepository userRepository) {
          this.userRepository = userRepository;
      }
  
      @Autowired
      public void setAuthorizationService(AuthorizationService authorizationService) {
          this.authorizationService = authorizationService;
      }
      // ... 你的业务方法
  }
  

• 重构代码打破循环（最推荐）：循环依赖往往意味着代码职责划分不清，把两个Service共享的逻辑抽成一个新的公共Service，让原来的两个Service都依赖这个新组件，而不是互相依赖。

场景3：Repository和Service互相依赖

这种情况很少见，但如果发生了，同样是重构——Repository只负责数据访问，不该依赖Service层的业务逻辑，把依赖Repository的Service逻辑调整到上层即可。

内容的提问来源于stack exchange，提问作者JONKI