依赖传递原则：Gradle 的依赖传递机制、强制依赖和动态依赖的区别，以及版本冲突是如何产生的

说实话，依赖管理这块，是很多 Android 开发同学的"噩梦起点"。我记得刚开始用 Gradle 那会儿，项目里莫名其妙多了好几个包，版本还互相打架，编译报错看得我一脸懵。后来才搞明白，这一切的根源，就是 依赖传递。

说白了，你依赖了一个库，这个库又依赖了别的库，那些"别的库"就会像亲戚串门一样，自动进到你的项目里。这就是 Gradle 的依赖传递机制。今天我们就把它彻底讲透。

依赖传递机制：Gradle 是怎么"传"依赖的

Gradle 默认开启了传递依赖（transitive）。什么意思呢？

• 你声明了 implementation 'com.example:lib-a:1.0.0'
• 如果 lib-a 本身又依赖了 com.example:lib-c:1.0.0
• 那么 lib-c 会自动成为你项目的间接依赖

我在项目中遇到过好几次这种情况：明明只配了两个直接依赖，结果编译时冒出来十几个包。用 ./gradlew dependencies 一看，好家伙，依赖树长得跟圣诞树似的。

// 查看依赖树的命令
./gradlew :app:dependencies --configuration implementation

// 输出示例（简化）
implementation
+--- com.example:lib-a:1.0.0
|    \--- com.example:lib-c:1.0.0  ← 传递过来的
\--- com.example:lib-b:2.0.0
     \--- com.example:lib-c:2.0.0  ← 也是传递过来的，但版本不同！

注意看，lib-a 和 lib-b 都传递了 lib-c，但版本一个是 1.0.0，一个是 2.0.0。这就出现了版本冲突。Gradle 遇到这种情况，默认会选择最高版本，但如果你没意识到这个选择，后面就可能埋坑。

强制依赖 vs 动态依赖：两种特殊依赖的差异

讲完传递机制，再说两个容易混淆的概念——强制依赖（force）和动态依赖（dynamic version）。这两兄弟看起来都像是"硬刚版本"，但本质完全不同。

// 强制依赖的写法
configurations.all {
    resolutionStrategy {
        force 'com.example:lib-c:2.0.0'
    }
}

// 动态依赖的写法
dependencies {
    implementation 'com.example:lib-c:2.+'      // 匹配 2.x 最新版
    // 或者
    implementation 'com.example:lib-c:latest.release'
}

我个人习惯尽量不用动态依赖。你想想看，今天编译好好的，明天 CI 上突然挂了，查了半天发现是某个小版本偷偷升级了——这种事我在团队里见过不止一次。

版本冲突：它到底是怎么冒出来的？

好，现在我们来拆解冲突的"罪魁祸首"。版本冲突说白了就一句话：

同一个库，被不同路径传递来了不同的版本。

举个例子：

• 你直接依赖了 lib-a（它依赖 lib-c:1.0）
• 你也直接依赖了 lib-b（它依赖 lib-c:2.0）
• 这时候 lib-c 就出现了两个版本 → 冲突了

Gradle 的默认策略是"最高版本胜出"。在上面的例子里，lib-c:2.0 会被选中，lib-c:1.0 被排除。听起来挺智能对吧？但问题在于——

lib-a 可能是在 lib-c:1.0 的 API 下开发的，如果 lib-c:2.0 有破坏性变更，lib-a 在运行时就会出问题。这就是运行时崩溃的典型来源，也是 AGP 版本冲突发布崩溃里最常见的案例。

实战避坑：我的经验总结

讲了这么多理论，最后分享几个实在的"保命技巧"：

• 每次加依赖，先跑依赖树：./gradlew :app:dependencies，花 30 秒看清全貌
• 锁定关键版本：用 resolutionStrategy.force 把核心库版本写死，避免被传递依赖覆盖
• 慎用 + 和 latest.release：除非你确定每天都会回归测试，否则锁死版本号
• 多用 constraints：Gradle 6.x 以后可以用 constraints 声明版本约束，比 force 更温和

// 使用 constraints 替代 force（推荐）
dependencies {
    constraints {
        implementation('com.example:lib-c:2.0.0') {
            because '所有依赖方均兼容此版本'
        }
    }
}

嗯，总结一下：依赖传递本身是个好机制，但你不能当甩手掌柜。每一条传递路径、每一个版本选择，都值得你多看一眼。这样真正遇到冲突崩溃时，你才能迅速定位、精准止血。