Spring自动配置中@Import为何忽略同配置类的@ConditionalOnBean条件

你遇到的现象完全符合Spring Boot的设计逻辑，不存在框架异常，核心是对@Conditional机制的规则存在认知盲区：

• 不同条件注解的执行阶段不同，拦截范围存在本质区别
  官方文档提到的“标注了@Conditional的配置类上的@Bean、@Import、@ComponentScan都会受条件约束”，仅针对执行阶段为配置元数据解析阶段（PARSE_CONFIGURATION）的条件，比如@ConditionalOnClass、@Profile这类。这类条件会在Spring读取配置类注解元数据的第一时间完成判定，如果条件不满足，直接跳过整个类的所有解析逻辑，不会触发类上的@Import导入、不会执行@ComponentScan的包扫描。
  但你使用的@ConditionalOnBean（对应OnBeanCondition实现），**刻意将自身的执行阶段设置为了BeanDefinition注册阶段（REGISTER_BEAN）**——因为如果在解析阶段检查Bean是否存在，很多后续才会被解析的Bean还未加载，判定结果完全不准确。
  这个阶段下，所有配置类的注解元数据早已解析完成：
  • 你在ImportSpecificConfig上标注的@Import(SpecificConfig.class)，早在解析阶段就已经把SpecificConfig加入到待解析队列，连SpecificConfig自己的@Import、@ComponentScan的扫描结果都已经处理完成
  • 等到进入Bean注册阶段，才轮到执行@ConditionalOnBean的判定：发现没有ConnectionFactory，所以跳过ImportSpecificConfig类本身的Bean定义注册、跳过类内部aBean()方法的Bean注册，这就是你观察到的SomeBean没有被实例化的原因
  • 但之前已经被加入解析队列的SpecificConfig及相关组件，不受这个后置的条件判定影响，还是会正常完成注册，自然就会出现依赖缺失的启动报错。
• 为什么直接给SpecificConfig加@ConditionalOnBean就生效
  因为SpecificConfig在Bean注册阶段被判定条件不满足时，它作为独立的配置类，自身关联的所有Bean定义会被整体跳过注册，连带它导入的组件、扫描的组件的注册逻辑也会被拦截。但这并不代表解析阶段没有处理这些注解，只是注册阶段被整体跳过了——这也是为什么这种方式在你当前的测试场景下能达到预期，但修改第三方类的方式本身不可行。

针对你“不修改第三方配置类、无指定Bean时完全不触发第三方配置类的导入和扫描逻辑”的需求，有两个落地性极强的实现方式：

1. 用自定义ImportSelector替代直接在类上写@Import
   把原来ImportSpecificConfig上的@Import(SpecificConfig.class)去掉，替换成自定义的导入逻辑：
   • 实现ImportSelector接口，重写selectImports方法
   • 在方法内通过传入的上下文拿到当前的BeanDefinitionRegistry，检查是否已经存在ConnectionFactory对应的BeanDefinition
   • 如果存在，返回SpecificConfig.class的全限定名；如果不存在，返回空数组
   • 把原来的@Import(SpecificConfig.class)改成@Import(CustomSpecificImportSelector.class)
     这个方式的好处是，导入类的判断逻辑完全在配置解析阶段执行，从根源上不会把不需要的SpecificConfig加入解析队列，后续自然不会触发它的包扫描、其他导入逻辑。
2. 自定义PARSE_CONFIGURATION阶段的条件注解
   写一个自定义的条件类，继承SpringBootCondition，重写getConfigurationPhase方法返回ConfigurationPhase.PARSE_CONFIGURATION，在匹配逻辑里检查BeanDefinitionRegistry中是否存在ConnectionFactory的BeanDefinition。
   因为你的自动配置类用了@AutoConfigureAfter(RabbitAutoConfiguration.class)，保证Rabbit相关的配置类会被提前解析、ConnectionFactory的BeanDefinition会提前注册，所以在解析阶段做这个判断是完全准确的，不会出现误判。这个条件的拦截效果和@ConditionalOnClass完全一致，会在解析阶段直接跳过整个类的所有逻辑，从根本上避免不需要的配置类被导入。

• 不要尝试在@ConditionalOnBean的使用场景下，靠它的后置判定拦截解析阶段的注解处理，这是Spring Boot长期稳定的设计逻辑，不是框架bug。
• 只要涉及到需要在配置导入、包扫描前做拦截的场景，优先选择执行阶段在PARSE_CONFIGURATION的实现逻辑，不要依赖注册阶段的条件注解。

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