本文详解如何在 build.gradle 中编程式获取和强制指定传递依赖（transitive dependency）的实际解析版本，并通过 exclude、force 和 resolutionstrategy 等机制实现构建时版本锁定，避免冲突且无需手动声明该依赖。
本文详解如何在 build.gradle 中编程式获取和强制指定传递依赖（transitive dependency）的实际解析版本，并通过 exclude、force 和 resolutionstrategy 等机制实现构建时版本锁定，避免冲突且无需手动声明该依赖。
在 Android 或 Java 项目中，当多个直接依赖引入了同一坐标（如 group:module）但不同版本的传递依赖时，Gradle 默认采用「版本冲突解决策略」——即选择最高版本（如 2.0.0 vs 3.0.0 → 选 3.0.0）。但有时业务逻辑要求严格遵循某条依赖链所带入的特定版本（例如上例中必须使用 my-dependency-1 所携带的 group:module:2.0.0），而非最高版或默认解析结果。此时，不能仅靠 implementation 'group:module:2.0.0' 手动声明（违背“不主动管理该依赖”的前提），而需在构建配置中编程式干预解析过程。
✅ 正确做法：三步精准控制传递依赖版本
1. 排除干扰源 —— 使用 exclude 阻断非目标依赖链的传递引入
针对你希望“让 my-dependency-2 不再带入 group:module”的需求，可在其声明时显式排除：
dependencies {
implementation "my-dependency-1:module:1.0.0" // ✅ 保留其传递的 group:module:2.0.0
implementation("my-dependency-2:module:1.0.0") {
exclude group: "group", module: "module" // ⚠️ 主动切断其传递路径
}
}该写法确保 group:module 仅来自 my-dependency-1，从而天然锁定为 2.0.0 —— 无需硬编码版本号，完全依赖其实际解析结果。
2. 强制统一解析 —— 使用 force 锁定全局版本（更通用方案）
若需进一步保障所有模块（包括未来新增依赖）均使用 2.0.0，可结合 resolutionStrategy 进行动态强制：
configurations.all {
resolutionStrategy {
force "group:module:2.0.0" // ✅ 全局强制使用此版本
// 或更灵活地：从某依赖的元数据中提取版本（需自定义逻辑）
}
}? 注意：force 会覆盖所有来源的版本选择，包括直接依赖与传递依赖，是生产环境推荐的确定性方案。
3. （进阶）运行时动态读取并注入版本 —— 利用 afterEvaluate + configurations 反射解析
若你坚持“完全不写死 2.0.0”，而是想在构建过程中自动探测 my-dependency-1 实际解析出的 group:module 版本，可借助 Gradle 的依赖图 API（需 Groovy/DSL 支持）：
afterEvaluate {
def targetGroup = "group"
def targetModule = "module"
// 获取 runtimeClasspath 配置中已解析的依赖树
configurations.runtimeClasspath.incoming.resolutionResult.allDependencies.forEach { dep ->
if (dep.selected &&
dep.selected.moduleVersion.group == targetGroup &&
dep.selected.moduleVersion.name == targetModule) {
println "✅ 自动检测到传递依赖版本: ${dep.selected.moduleVersion.version}"
// 此处可将 version 存入 ext 属性，供后续逻辑使用
ext.transitiveModuleVersion = dep.selected.moduleVersion.version
}
}
}⚠️ 注意：该方式依赖于 runtimeClasspath 已完成解析（故需 afterEvaluate），且无法在 dependencies 块内直接用于 force（因执行顺序限制），通常用于日志审计或生成版本报告。
? 关键注意事项与最佳实践
- exclude 是最轻量、最安全的起点：它不改变依赖图结构，仅移除特定路径，符合“最小干预”原则；
- 避免滥用 force：虽能保证一致性，但可能掩盖兼容性风险，建议配合 ./gradlew app:dependencies --configuration releaseRuntimeClasspath 定期验证；
-
JCenter 已弃用，请立即迁移：截至 2026 年，所有新项目应使用 mavenCentral() 或 google() 仓库，旧配置需清理：
repositories { mavenCentral() // ✅ 替代 jcenter() google() // ✅ Android 官方库首选 } - *版本动态化慎用 + 或 `latest.**：它们破坏构建可重现性，CI/CD 中严禁使用；应始终采用语义化固定版本（如2.0.0）或1.5.+`（仅限开发调试）。
✅ 总结
要“编程式获取并锁定传递依赖版本”，核心不是“读取版本号”，而是通过依赖图控制策略实现版本收敛。优先使用 exclude 隔离干扰源，辅以 force 保障全局一致，必要时用 resolutionStrategy + afterEvaluate 实现高级自动化。这种方式既满足“不手动声明依赖”的约束，又确保构建结果稳定、可复现、易维护。
