gradle 排除传递依赖需精准切断间接依赖链，核心是在具体依赖声明内用 exclude 指定 group 和 module，或用 transitive = false 关闭全部传递依赖，也可在 configurations.all 中批量排除，最后须用 dependencies 任务验证生效。

Gradle 中排除传递依赖，核心是控制“谁引入了什么、要不要留”，不是简单删掉，而是精准切断不需要的间接依赖链。关键在于明确排除位置、粒度和时机。

明确在哪个依赖声明里排除

排除操作必须写在具体依赖项内部，不能放在全局配置里。Gradle 不允许对未声明的依赖做 exclude，所以得找到那个“带病”的父依赖。

• 比如某 SDK 自带旧版 log4j，而你项目已用 slf4j 统一日志，那就得在引入该 SDK 时排除：

implementation('com.example:sdk:3.2.0') {
  exclude group: 'log4j', module: 'log4j'
}

注意：group 对应 Maven 坐标中的 groupId，module 对应 artifactId；两者必须写全，只写一个可能无效。

排除整个传递依赖树（慎用）

有时某个依赖自带一整套冗余生态（如 Spring Boot starter 默认带 Tomcat，但你在打 war 包时想换 Jetty），可用 transitive = false 关闭全部传递依赖：

implementation('org.springframework.boot:spring-boot-starter-web') {
  transitive = false
}

但这会一并去掉所有有用依赖（比如 spring-web、jackson-databind），后续需手动补全，适合高度定制场景，不推荐日常使用。

Gradle 9.8.0

下载

批量排除多个模块或按规则过滤

当多个依赖都引了同一类旧库（如多个组件都带 commons-collections 3.x），可在 configurations 级别统一处理：

configurations.all {
  exclude group: 'commons-collections', module: 'commons-collections'
  exclude group: 'org.apache.logging.log4j', module: 'log4j-core'
}

这种方式作用于所有配置（compileClasspath、runtimeClasspath 等），适用于全局清理已知风险组件，但要注意别误伤必需依赖。

验证是否真正排除成功

排除后务必验证——运行以下命令查看实际生效的依赖树：

./gradlew app:dependencies --configuration runtimeClasspath | grep -A 5 -B 5 "log4j"

如果输出里不再出现被排除的模块，说明生效；若仍有残留，可能是：

• 排除写错 group/module 名（区分大小写、连字符）
• 其他依赖路径又悄悄引入了同一模块
• 用了 api 或 compileOnly 等配置，导致排除未覆盖到对应 classpath

不复杂但容易忽略。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南