依赖冲突原理：Maven依赖仲裁、强制版本声明、exclude与force的使用场景
依赖冲突，说白了就是多个库同时引用了同一个库的不同版本。Gradle 到底该用哪个？用错了就会抛 NoSuchMethodError 或 ClassNotFoundException。
我个人习惯把依赖冲突分成两类：
- 良性冲突 —— 版本差异很小，Gradle 自动仲裁后还能正常跑。但别高兴太早，暗坑很多。
- 致命冲突 —— API 不兼容，运行时直接崩。我遇到最惨的一次，因为
okhttp3.12 和 4.0 混用，WebSocket 握手怎么都过不去。
本章咱们把 Maven 依赖仲裁、强制版本、exclude 和 force 这四个核心机制掰开揉碎讲清楚。嗯，先看张总览图，心里有个框架。
Maven 依赖仲裁：Gradle 的默认规则
Gradle 默认走 Maven 的仲裁策略——最短路径优先。什么意思呢？就是看哪个依赖的传递层级最少，就用哪个版本。
举个例子：
app 依赖库 A 的 v1.0，而库 A 又依赖库 C 的 v2.0
app 直接依赖库 B，而库 B 依赖库 C 的 v1.5
结果：Gradle 会选择 C v1.5（路径更短：app->B->C，只有2层）如果路径长度相同呢？那就看谁在 dependencies 块里先声明。先声明者获胜。我记得有次排查问题，就因为调整了依赖声明顺序，模块编译结果都变了。
./gradlew :app:dependencies 命令查看依赖树，箭头 -> 指向的就是被仲裁选中的版本。
强制版本声明：让 Gradle 听你的
仲裁毕竟是个“自动”机制，有时候它选出来的版本就是不对。这时候需要手动干预。最硬核的方式就是 强制版本。
在 Gradle 里有两种写法：
- 全局 force —— 在
dependencies块里加force = true - strictly 声明 —— 声明必须使用某个版本，违反就报错
看代码最直观：
// 方式一：force
implementation('com.squareup.okhttp3:okhttp:4.9.3') {
force = true
}
// 方式二：strictly（推荐，更安全）
implementation('com.squareup.okhttp3:okhttp') {
version {
strictly '4.9.3'
}
}我个人习惯用 strictly。为什么？因为 force 是静默覆盖，万一有库明确依赖了更高版本而且必须有新 API，你会被坑。而 strictly 会在冲突时直接报错，逼你主动解决。
force = true，导致某个安全补丁版本始终升不上去。查了一整个下午才发现是 force 把依赖树锁死了。所以 force 要像抗生素一样——别滥用。
exclude：精准切除冲突的传递依赖
有时候冲突的根源是某个库的 传递依赖 引了一个你不想要的包。这时候 exclude 是最优雅的干预方式。
语法很简单：
implementation('com.example:library:1.0') {
exclude group: 'com.unwanted', module: 'bad-library'
// 或者只排除 group
exclude group: 'com.unwanted'
}举个真实场景：项目里同时用了 AndroidX 和旧版 support 库。某个老掉牙的第三方库在传递依赖里拉进了 com.android.support:appcompat-v7，和新版 AndroidX 冲突。二话不说，直接 exclude 掉：
implementation('com.old.thirdparty:sdk:2.3') {
exclude group: 'com.android.support'
}然后手动补一个 AndroidX 版本的依赖即可。
四者关系总结
说了这么多，咱们用一张表收一下：
| 机制 | 作用范围 | 优先级 | 风险 | 推荐场景 |
|---|---|---|---|---|
| Maven 依赖仲裁 | 全局自动 | 最低 | 低（但可能选错版本） | 无明显冲突时默认采用 |
| exclude | 单个依赖 | 中等 | 低（精准切除） | 排除某个不想要的传递依赖 |
| strictly 声明 | 全局或模块 | 高 | 中（会阻断升级） | 必须固定版本且希望冲突时报错 |
| force | 全局 | 最高 | 高（静默覆盖所有其他版本） | 紧急修复、临时锁定 |
实战排查步骤（我的习惯）
遇到依赖冲突，我一般按下面顺序来：
- 先看编译报错信息——Gradle 会在
BUILD FAILED后面告诉你哪些模块冲突了，一般还列出了所有候选版本。 - 再跑依赖树——
./gradlew app:dependencies | grep "->"找出最终被选中的版本。 - 分析路径——是路径问题就用
exclude切掉中间库的传递依赖；是版本不兼容就考虑strictly。 - 实在不行再用
force——但记得加注释说明原因，方便后来人（也包括你自己）维护。
🎯 核心原则：能用 exclude 解决的问题，不要用 force。能用 strictly 的就别用 force。force 是你的最后一张底牌，打出去就别想轻易回收。
避坑案例：我曾踩过的 force 巨坑
去年做一个视频播放器 SDK 的集成，合作方提供的 aar 里强力依赖了 exoplayer:2.18。我图省事在 app 层用了 force = true 强行拉到 2.19。结果跑起来播放列表 UI 样式全都乱了——因为 2.19 改动了内部 View 的 LayoutParams。
调试了整整一天才发现是 force 把 SDK 预期依赖的旧版本给覆盖了。那时候我就给自己立了个规矩：force 必须配注释，且只能用于自己掌控的一方依赖。