第1章 依赖冲突的本质与产生路径
1.1 依赖冲突的本质
Gradle 依赖冲突的本质是 同一模块（GAV坐标完全相同）被不同路径引入两个或多个不兼容版本。Gradle 默认采用“最新版本胜出”策略，但这会导致运行期 NoSuchMethodError、ClassNotFoundException 等难以追踪的错误。冲突不是直接报错，而是“沉默地覆盖”，因此需要主动治理。
关键指标：在
gradle dependencies 输出中，-> 表示版本上升，(*) 表示被冲突覆盖。出现大量 (*) 的模块就是冲突热点。
1.2 产生路径：四种主要来源
| 路径 | 说明 | 示例 |
|---|---|---|
| 传递依赖 | A → B → C:1.0，D → C:2.0，C 出现两个版本 | com.google.guava:guava:30.1-jre 与 30.0-jre |
| 版本覆盖（默认策略） | Gradle 自动选取版本树中的最高版本，覆盖其他版本 | 最高版本可能是“错误版本” |
| 动态版本 | 1.+ 或 latest.release 导致构建时版本不固定，不同环境可能拉取不同版本 |
implementation 'com.example:lib:2.+' |
| 人为冲突 | force = true、strictly、required 声明互相矛盾 |
两个模块对同一依赖指定了不同 strictly |
常见陷阱：动态版本不会触发 Gradle 的冲突报告（因为每次解析都是最新），但会导致构建不可复现。生产环境必须使用固定版本。
1.3 冲突类型：strict vs required vs force
Gradle 提供了三种显式约束机制，优先级从高到低为：strictly > required > force。它们的行为差异如下：
| 类型 | 声明方式 | 行为特征 | 冲突生效条件 |
|---|---|---|---|
strictly |
strictly '2.0' |
强制使用指定版本，若与其他 strictly 冲突则构建失败 |
所有 strictly 必须一致，否则抛出 DependencyResolutionException |
required |
require '2.0' |
声明“最低要求版本”，Gradle 会在满足所有 required 的前提下选最高版本 |
与 required 版本不兼容时选用更高的满足版本 |
force |
force = true（已过时） |
强制覆盖其他所有版本，即使其他版本更高 | 总是生效，但会抑制正常的冲突报告，不推荐 |
1.4 冲突日志解读
执行 gradle dependencies --configuration runtimeClasspath 后典型输出：
+--- com.example:lib-a:1.0
| \--- com.google.guava:guava:30.0-jre -> 30.1-jre (*)
+--- com.example:lib-b:2.0
| \--- com.google.guava:guava:30.1-jre
\--- com.google.guava:guava:30.1-jre-> 30.1-jre 表示版本从 30.0 被提升到 30.1；(*) 表示该依赖已被全局版本覆盖，实际不再生效。如果出现 com.example:lib-c:3.0 -> com.google.guava:guava:29.0 且无 ->，说明 29.0 被直接保留，但可能与其他路径冲突。
调试命令速查：
gradle dependencyInsight --dependency guava --configuration runtimeClasspath查看特定模块的冲突原因gradle build --scan生成构建扫描，可视化依赖树
1.5 依赖冲突产生路径全景图
1.6 典型错误与稳定性优化建议
- 错误1：使用
force = true后忽略冲突报告，导致运行时异常。推荐替换为strictly或required。 - 错误2：动态版本（
1.+）在 CI 和本地构建出不同依赖树，破坏可复现性。应锁定到具体版本。 - 稳定性优化：在
build.gradle中添加configurations.all { resolutionStrategy.failOnVersionConflict() }，让冲突在构建期失败而不是运行时。