@ConditionalOnBean未检测到已创建Bean的问题咨询

这是一个典型的Spring条件注解评估时机与Bean注册顺序不匹配的问题，我来一步步拆解原因和解决办法：

核心原因：条件评估早于目标Bean的注册 #

Spring在处理组件（不管是通过@Component扫描还是自动配置类）时，会先评估@Conditional系列注解的条件，这个阶段发生在Bean定义注册阶段，远早于Bean的实例化阶段。也就是说：

• 当Spring检查AnotherService的@ConditionalOnBean条件时，ExampleServices的Bean定义可能还没被注册到Spring上下文里（比如ExampleServiceConfig的处理顺序滞后于AnotherService的组件扫描）。
• 你看到的exampleServices实例化日志，只是Bean创建的时间点，而条件判断在更早的阶段就已经完成了——一旦条件评估不通过，Spring就会直接跳过AnotherService的Bean创建流程，后续哪怕ExampleServices被实例化，也不会再回头处理它。

关于日志顺序的误导 #

你提到“未匹配”日志出现在Bean创建之后，这是因为Spring的日志输出顺序不一定严格对应执行顺序：

• 可能Spring先批量完成了所有组件的条件评估，然后再批量实例化符合条件的Bean，但日志输出时先展示了实例化的内容，再补输出之前的条件评估结果；
• 或者AnotherService的条件评估是在上下文刷新的后期执行的，但此时它的Bean定义已经被标记为不匹配，不会再被处理。

可行的解决方法 #

方法1：调整@ConditionalOnBean的搜索策略

默认的SearchStrategy.CURRENT只会搜索当前阶段已注册的Bean，改成SearchStrategy.ALL后，会搜索所有上下文（包括父上下文）中已注册的Bean定义，能覆盖后续注册的Bean：

@ConditionalOnBean(value = ExampleServices.class, search = SearchStrategy.ALL)
public class AnotherService{
    @Autowired
    public AnotherService(ExampleServices exampleServices){
        this.exampleServices = exampleServices;
    }
}

方法2：将AnotherService作为配置类的@Bean方法

把AnotherService的创建逻辑放到同一个配置类中，Spring会自动处理Bean的依赖顺序，确保先注册ExampleServices，再评估AnotherService的条件：

@Configuration
public class ExampleServiceConfig {
    @Bean
    @ConditionalOnProperty(value = "servicefeature1.enable", havingValue = "true")
    public ExampleServices exampleServices() {
        return new ExampleServices();
    }

    @Bean
    @ConditionalOnBean(ExampleServices.class)
    public AnotherService anotherService(ExampleServices exampleServices) {
        return new AnotherService(exampleServices);
    }
}

这种方式下，Spring会先完成exampleServices的Bean注册，再检查anotherService的条件，此时条件必然匹配成功。

方法3：统一依赖配置属性

既然ExampleServices的创建依赖servicefeature1.enable=true，直接让AnotherService也依赖同一个属性，完全避开Bean注册顺序的问题：

@ConditionalOnProperty(value = "servicefeature1.enable", havingValue = "true")
public class AnotherService{
    @Autowired
    public AnotherService(ExampleServices exampleServices){
        this.exampleServices = exampleServices;
    }
}

这种方式逻辑更直接，也避免了条件判断依赖Bean状态带来的不确定性。

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