同一Spring Boot Starter依赖设provided与compile scope致自动配置异常问题

核心原因 #

1. Maven重复依赖的解析规则
   当同一个Spring Boot Starter在项目A中被同时声明为provided和compile scope时，Maven会遵循依赖调解规则，以最后声明的依赖条目配置为准：

   • 如果最终生效的是compile scope，该Starter会自动传递到项目B的类路径中；
   • 如果最终生效的是provided scope，该Starter不会传递给B，仅在A的编译阶段可见。

2. Spring Boot自动配置的条件触发机制
   即使Starter出现在B的类路径中，其自动配置类的生效并非无条件，而是依赖于Spring的条件注解（如@ConditionalOnClass、@ConditionalOnBean）：

   • 当B使用A中的类时，Spring会加载A的相关类/Bean，满足自动配置的前置条件，因此配置正常生效；
   • 当B不使用A中的类时，若B的@ComponentScan未覆盖A的包路径，A的类/Bean不会被Spring扫描加载，自动配置的条件不满足，导致配置无法生效。

3. 对自动配置生效逻辑的误解
   你预期自动配置始终生效，是默认认为只要Starter在类路径中就会触发，但实际上Spring Boot的自动配置设计是按需生效，严格遵循条件注解的规则，避免不必要的配置加载。

解决方案 #

• 清理重复依赖：移除项目A中重复的Starter依赖，仅保留compile scope的声明，消除Maven依赖解析的歧义，确保Starter能稳定传递到B的类路径中。
• 调整自动配置条件：若需强制自动配置始终生效，可检查Starter自动配置类的条件注解，移除依赖于A中类/Bean的条件，或在项目B中主动引入该Starter。
• 确保组件扫描范围：在项目B的启动类上添加@ComponentScan(basePackages = "com.your.projectA.package")，确保A中的类/Bean能被Spring扫描到，满足自动配置的条件。

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