Spring Boot分层Starter中@ConditionalOnMissingBean替换Bean报错如何解决

出现BeanDefinitionOverrideException的核心原因是Spring Bean的注册顺序不符合@ConditionalOnMissingBean的生效预期，你可以按优先级从高到低选择以下方案解决：

• 调整自动配置类加载顺序
  给SCA的自动配置类添加@AutoConfigureBefore(SA对应自动配置类.class)注解，保证SCA的配置类比SA的对应配置类先执行。SCA的Bean会优先注册，SA的配置类执行时，@ConditionalOnMissingBean检测到同类型Bean已存在，就会跳过SA的Bean注册，从根源避免冲突。
  注意：两个Starter的自动配置类必须通过Spring Boot自动配置机制注册（即通过META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports或旧版的spring.factories文件声明），不能被业务应用的@ComponentScan直接扫描，否则@AutoConfigureBefore的顺序控制不会生效。
• 校验条件注解匹配规则
  确认SA的@ConditionalOnMissingBean注解的匹配规则和你预期一致：默认是按Bean类型匹配，如果你要按Bean名称匹配，需要显式指定@ConditionalOnMissingBean(name = "bean名称")，避免类型不匹配导致条件失效，重复注册Bean。
• 配置允许Bean覆盖（不推荐优先使用）
  如果你暂时无法调整配置顺序，可以在应用的配置文件中添加spring.main.allow-bean-definition-overriding=true，允许同名称Bean的后注册实例覆盖先注册的实例。但这个方案会掩盖其他非预期的Bean覆盖问题，仅建议作为临时方案使用。

你当前的Starter层级设计是合理的，完全符合Spring Boot Starter的分层复用最佳实践：

• 父POM层（SAP、SCAP）拆分公共依赖和场景专属依赖统一管理，避免业务应用重复声明依赖、出现版本冲突问题。
• Starter能力层（SA、SCA）拆分通用基础能力和细分场景定制能力，SCA复用SA的基础逻辑仅做差异化调整，符合开闭原则，后续扩展其他场景的Starter时也可以复用这套层级结构。
• 可优化点：建议将SA、SCA的自动配置类放在不会被业务应用默认扫描到的独立包路径下，完全通过自动配置注册机制加载，避免业务侧扫描路径配置不当导致的Bean重复注册、顺序混乱问题。

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