Spring Boot多Profiles拆分Stub时@ComponentScan排除规则冲突导致注入异常

你的推测完全正确：Spring 中多个配置类的@ComponentScan是独立执行的，各自的排除规则不会合并。StubConfV3Configuration的扫描逻辑仅排除了持久层包，仍会将databackendapi路径下的原生DataBackendApi扫描注册为Bean，和StubDataBackendConfiguration中声明的Stub Bean同时存在，最终触发同类型Bean不唯一的注入冲突。

方案1：移除Stub配置类的全量包扫描，从根源避免冲突 #

这是最符合Spring设计规范、灵活度最高的方案：

1. 删除两个Stub配置类上的@ComponentScan和@EnableAutoConfiguration注解（全量扫描和自动配置统一由主启动类负责即可），仅保留Stub Bean的声明逻辑：
   DAO层Stub配置调整后：

   @Configuration
   @Profile("stubconfv3")
   public class StubConfV3Configuration {
       @Bean
       public RefDayDao refDayDao() { return new RefDayInMemoryDao(); }
       @Bean
       public RefTypeHourDao refTypeHourDao() { return new RefTypeHourInMemoryDao(); }
   }
   

   外部webservice层Stub配置调整后：

   @Configuration
   @Profile("stubdatabackend")
   public class StubDataBackendConfiguration {
       @Bean
       public DataApi consumptionApi() { return new DataStubApi(); }
   }
   

2. 给原生实现类添加Profile条件，避免Stub场景下被注册：
   给原生DAO实现类添加@Profile("!stubconfv3")注解，给原生DataBackendApi添加@Profile("!stubdatabackend")注解，对应Stub profile激活时原生实现会自动跳过注册，完全不会出现同类型Bean冲突的问题，且两个Stub profile可以完全独立启用/停用，灵活性拉满。

方案2：统一控制包扫描规则 #

如果不想改动原生实现类的注解，可以把所有排除规则统一放到主启动类的@ComponentScan中，通过Spring的属性注入动态控制排除规则，或者直接固定排除persistence和databackendapi路径，这两个路径下的Bean仅通过配置类按需注册即可。

如果需要快速解决问题不想调整现有结构，可以直接给所有Stub Bean添加@Primary注解：

@Bean
@Primary
public DataApi consumptionApi() { return new DataStubApi(); }

当同类型Bean存在时，Spring会优先注入带@Primary的Stub Bean，无需修改其他业务逻辑即可解决注入异常。

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