为何近乎相同的Spring Boot服务无需@ComponentScan即可访问库Bean？

以下是几个最可能导致差异的核心原因，均围绕Spring Boot的自动装配和测试切片机制展开：

• 内部公共库的Bean注册方式不同
  参考服务依赖的内部库，大概率是通过自动配置类完成Bean注册的：

  • 库中使用@Configuration+@Bean定义Bean，并在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（Spring Boot 2.7+）或META-INF/spring.factories（旧版本）中声明配置类，让Spring Boot自动扫描加载，无需显式@ComponentScan。
  • 而你的服务依赖的内部库，可能是靠@Component+外部@ComponentScan来扫描Bean，必须显式添加扫描注解才能加载，这就导致测试切片也会触发全量Bean扫描，引发依赖缺失问题。

• 主启动类的扫描范围控制差异
  参考服务的主启动类没有显式添加@ComponentScan，Spring Boot默认只会扫描主类所在包及其子包的Bean，而内部库的自动配置类不受此限制，会被Spring Boot自动装配机制加载。
  你的服务主类可能添加了@ComponentScan并指定了包含内部库的包范围，这会让测试切片（如@DataJpaTest）也继承这个扫描范围，试图加载库中所有Bean，但测试切片的极简上下文无法满足部分Bean的依赖（比如非JPA相关的服务、配置Bean）。

• 内部库Bean的条件注解配置差异
  参考服务的内部库Bean可能添加了条件注解（如@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnBean），在@DataJpaTest的极简上下文里，这些条件不满足，无法装配的Bean会被自动跳过。
  你的服务依赖的内部库Bean没有这些条件限制，测试切片会尝试加载所有被扫描到的Bean，导致无法装配的错误。

• 依赖的Starter封装差异
  参考服务的内部库被封装成了Spring Boot Starter（即包含spring-boot-starter依赖和自动配置的Jar），Starter的自动装配逻辑会被Spring Boot自动识别，无需手动扫描。
  你的服务依赖的内部库只是普通Jar，没有Starter封装，必须通过@ComponentScan才能加载其中的Bean。

• Spring Boot版本的细微行为差异
  即使大版本一致，小版本的差异也可能导致测试切片的扫描逻辑变化：比如某些版本中@DataJpaTest对显式@ComponentScan的处理优先级不同，或者自动配置类的加载顺序有调整，引发不同的表现。

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