为何部分Gradle依赖需重复声明才能被微服务正常使用？

以下是几种常见的原因，对应不同的场景：

• 依赖传递性被配置限制
  Gradle默认支持依赖传递，但如果项目A中Spring Security依赖的配置是compileOnly、testImplementation这类不传递的范围，项目B就无法间接获取到该依赖。比如你在A的build.gradle里写了：

  compileOnly 'org.springframework.boot:spring-boot-starter-security'
  

  这种配置下，依赖仅在A的编译阶段生效，不会传递给依赖A的项目B，必须在B中显式添加。

• Gradle依赖可见性设置问题
  这是最常见的原因：如果项目A用implementation配置引入Spring Security：

  implementation 'org.springframework.boot:spring-boot-starter-security'
  

  implementation的依赖仅对A自身的编译、运行可见，不会暴露给上层项目B的编译路径。如果项目B的代码直接用到了Spring Security的类（比如@PreAuthorize注解、Security配置类），编译阶段就会报错，必须在B里显式添加依赖。
  要是想让依赖自动传递给B，项目A应该改用api配置：

  api 'org.springframework.boot:spring-boot-starter-security'
  

• Spring Boot依赖管理的版本冲突
  如果项目A不是Spring Boot项目，而项目B是，两者的依赖版本可能不兼容。Spring Boot的spring-boot-dependencies BOM会统一管理依赖版本，若A引入的Spring Security版本和B的BOM版本不一致，可能导致依赖传递后无法正常加载，显式添加依赖能让B使用自身BOM管理的兼容版本。

• 间接依赖缺失
  有时候依赖传递了，但Spring Security的某些间接依赖可能因为版本冲突被Gradle自动排除，导致运行时找不到核心类。显式添加依赖会强制引入完整的依赖链，修复缺失问题。

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