Gradle依赖冲突需据场景选干预方式：全局强制用resolutionStrategy.force，多模块推荐constraints声明约束，局部冲突用exclude+显式声明；务必先分析依赖树再操作。
Gradle 默认按“最高版本优先”选依赖，但实际项目中经常不生效——比如 Spring Boot BOM 锁了旧版、某个间接依赖硬塞进低版本、或者多个子模块各自声明不同版本。这时候光靠写 implementation 'x:y:z' 没用，必须用明确的干预手段。
用 resolutionStrategy.force 全局强制版本
这是最直接、覆盖最全的方式，适合 Android 项目或单模块强控场景。
- 写在
configurations.all块里，对所有配置（implementation、testImplementation等）生效 - 语法是
force 'group:name:version'，注意引号不能少 - 它会覆盖所有传递依赖中对该库的任何版本声明，包括 BOM 里的定义
- 风险：如果强制的版本和某依赖二进制不兼容（比如 Kotlin 1.5 强制给用了 1.8 编译的库），运行时可能
NoClassDefFoundError
示例：
configurations.all {
resolutionStrategy {
force 'org.jetbrains.kotlin:kotlin-stdlib:1.7.10'
force 'com.squareup.okhttp3:okhttp:4.12.0'
}
}
用 constraints 声明版本约束（推荐用于多模块 / Spring Boot 项目）
Gradle 5.0+ 主推的方式，语义更清晰，且和 BOM 兼容性更好。
-
constraints不会主动拉取依赖，只起“规则”作用；只有当某依赖真正被引入时，才按此规则解析版本 - 配合
platform使用效果最佳：BOM 提供版本基线，constraints在其基础上微调 - 支持
because注释，方便团队理解为什么锁这个版本（比如 “修复 CVE-2023-xxx”） - 不会像
force那样粗暴覆盖，更适合长期维护的工程
示例：
dependencies {
implementation platform('org.springframework.boot:spring-boot-dependencies:3.2.0')
constraints {
implementation('org.slf4j:slf4j-api:2.0.9') {
because '2.0.9 修复了 MDC 清理泄漏问题'
}
}
}
用 exclude + 显式声明组合处理局部冲突
当只有一两个依赖带进来坏版本，其他路径都正常时，比全局 force 更精准。
- 先用
exclude切断问题来源（比如某个 SDK 引入了老旧的guava） - 再单独
implementation你需要的干净版本 - 注意：只排除
group或module，别漏掉classifier（如:android） - 执行
./gradlew dependencyInsight --dependency guava --configuration runtimeClasspath可快速定位谁带进了冲突版本
示例：
dependencies {
implementation('com.some.sdk:sdk:2.1.0') {
exclude group: 'com.google.guava', module: 'guava'
}
implementation 'com.google.guava:guava:32.1.3-jre'
}
真正难的不是选哪种方式，而是判断「该不该强制」：有些版本冲突只是警告，不影响运行；有些却是类加载失败的前兆。务必先用 ./gradlew app:dependencies 看树，再用 dependencyInsight 定位源头，最后动手——否则很容易把一个 bug 换成三个新 bug。
