Gradle中同一库多版本不是“能否用”而是“何时炸”的问题：构建通常通过，但运行时易抛NoSuchMethodError或ClassNotFoundException；应优先用./gradlew :app:dependencies --configuration runtimeClasspath和dependencyInsight查清冲突，用exclude精准切断传递依赖，慎用force，推荐BOM统一版本管理，并仅在真实构建失败或运行异常时干预。
Gradle 同一个库出现多个版本，不是“能不能用”的问题，而是“什么时候炸”的问题。它大概率不会在 ./gradlew build 阶段报错，但会在运行时抛出 NoSuchMethodError、ClassNotFoundException，甚至 CheckDuplicateClassesRunnable 构建失败——这些都不是 Gradle 主动告诉你“这里有冲突”，而是它默默选了一个版本后，别的库不认了。
怎么看清楚到底哪些版本在打架
别猜，直接看依赖树。最有效的是两个命令组合使用：
-
./gradlew :app:dependencies --configuration runtimeClasspath：输出运行期实际加载的依赖链，搜索目标库名（如com.google.guava:guava），重点关注带->的行（表示被选中的版本）和带(*)的行（表示被仲裁掉但依然存在） -
./gradlew :app:dependencyInsight --dependency com.google.guava:guava --configuration runtimeClasspath：精准聚焦某一个坐标，直接列出所有引用路径和仲裁结果，比如输出里会明确写com.google.guava:guava:31.1-jre (selected by rule)，下面跟着谁要求了28.0-jre、谁又要求了30.1.1-android
注意：不要只看 compileClasspath，很多冲突只在 runtimeClasspath 或 debugRuntimeClasspath 下暴露；Android 项目尤其要留意 -android 和 -jre 变体共存导致的 Duplicate class 错误。
排除传递依赖比 force 更安全
当某个第三方库（比如 com.example:network-sdk:2.3）偷偷带进了一个老版本的 okhttp，而你项目里已经显式用了 4.12.0，优先用 exclude 切断它的传递依赖，而不是全局 force：
implementation('com.example:network-sdk:2.3') {
exclude group: 'com.squareup.okhttp3', module: 'okhttp'
}
这样做的好处是：
- 不影响其他模块对 okhttp 的正常依赖
- 避免因
force导致某个库内部调用被删掉的方法而崩溃 - 语义清晰：你知道这个排除只针对这一处，不是拍脑袋压版本
慎用 configurations.all { resolutionStrategy { force ... } }，它会强行覆盖整个项目的解析结果，容易引发连锁不兼容。
用 BOM 统一管理一组相关库的版本
如果你的项目大量使用 Spring、OkHttp、Guava 等有配套生态的库，且它们之间存在交叉依赖，BOM（Bill of Materials）是比逐个 exclude 或 force 更可持续的方式：
implementation platform('com.squareup.okhttp3:okhttp-bom:4.12.0')
implementation 'com.squareup.okhttp3:okhttp'
implementation 'com.squareup.okhttp3:logging-interceptor'
这样做的关键点：
- BOM 本身不带代码，只声明版本约束；所有子模块只要没显式指定 version，就会被自动锁定到 BOM 定义的版本
- 必须把
platform(...)放在所有具体依赖之前，否则约束不生效 - 不是所有库都提供官方 BOM，得查对应 Maven 仓库确认是否存在
-bom后缀的 artifact
AndroidX 从 1.0.0 开始也提供了 androidx-core:core-bom，值得接入。
真正难的不是解决，是识别“该不该动”
很多团队一看到 dependencies 输出里有多个版本就急着排除或强制，结果修好了 A 错误，却触发了 B 库的 IncompatibleClassChangeError。根本原因是没区分“冲突是否真实影响运行”。判断依据只有两个：
- 构建是否失败（如
CheckDuplicateClasses） - 运行时是否真的调用了冲突版本间的不兼容 API（看堆栈里
NoSuchMethodError的类和方法是否来自你控制之外的传递依赖）
如果只是依赖树里“看起来乱”，但构建通过、功能正常、日志无异常，那 Gradle 默认选的最高版本大概率就是可用的——别为整洁感牺牲稳定性。
