在gradle中排除传递依赖需精准定位问题来源，通过dependencyinsight查路径，在具体依赖声明中用exclude排除指定模块，或全局配置force统一版本并验证生效。
在 Gradle 中排除特定传递依赖，核心是“在哪排除、排除谁、是否影响其他路径”，不是全局删减，而是精准切断冗余依赖链。操作前务必先定位问题来源，再选择合适方式。
先查清谁引入了冲突包
运行命令看真实依赖树，找到冲突模块的引入路径：
- 查看运行时依赖树：`./gradlew app:dependencies --configuration runtimeClasspath`
- 聚焦某个库（如 guava）：`./gradlew app:dependencyInsight --dependency com.google.guava:guava --configuration runtimeClasspath`
- 输出中注意 →（最终选用版本）和 (*)（被仲裁掉的版本），以及每一行开头的依赖路径（如 `+--- com.example:sdk:2.1.0`），它就是你要动手排除的“父依赖”
在具体依赖声明里排除单个模块
这是最常用、最安全的方式，只影响那个直接依赖，不波及其他路径：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 语法必须写全 group 和 module，大小写、连字符都不能错：
implementation('com.example:sdk:2.1.0') { exclude group: 'log4j', module: 'log4j' } - 排除多个模块可连续写：
implementation('org.apache.kafka:kafka-clients:3.7.0') { exclude group: 'org.slf4j', module: 'slf4j-simple'; exclude group: 'junit', module: 'junit' } - 确认 group/module 名称的最可靠方法：从
dependencies输出中直接复制那一行的坐标
批量排除或统一约束版本
当多个依赖都带同一旧包（如 commons-logging、old-gson），适合集中处理：
-
全局排除某模块（慎用）：
configurations.all { exclude group: 'commons-logging', module: 'commons-logging' }
它作用于所有 classpath（compile、runtime 等），但可能误伤必需项，建议仅用于确认完全无用的组件 -
强制统一版本（推荐替代排除）：
configurations.all { resolutionStrategy { force 'com.google.code.gson:gson:2.10.1' } }
不删依赖，而是让所有路径都使用指定版本，更稳妥，尤其适合安全修复场景
验证是否真正生效
排除后必须验证，否则可能白忙一场：
- 再次运行
./gradlew app:dependencies --configuration runtimeClasspath | grep -i "log4j"，确认输出里不再出现被排除的 module - 如果仍有残留，常见原因有：
—— exclude 写错了 group 或 module（比如把log4j-core写成log4j）
—— 其他依赖路径又悄悄引入了同一模块（需继续追查）
—— 用了api或compileOnly配置，而 exclude 只对implementation生效，需对应调整
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
