10、依赖管理基础：仓库配置、依赖声明、依赖传递性、依赖冲突解决

依赖管理，说白了就是 Gradle 帮你搞定「你的代码需要哪些 jar 包」这件事。我刚开始用 Maven 那会儿，最头疼的就是 pom.xml 里写一堆依赖，还得手动处理版本冲突。后来转到 Gradle，发现它的依赖管理设计得确实更灵活，也更符合直觉。

这一章我们就把依赖管理的四个核心环节讲透：仓库去哪找、依赖怎么声明、传递性依赖怎么控制、冲突怎么解决。嗯，这些都是日常构建中绕不开的硬功夫。

10.1 仓库配置：告诉 Gradle 去哪找依赖

仓库就是 jar 包的「超市」。Gradle 支持多种仓库类型，最常用的就是 Maven 仓库和 Ivy 仓库。我个人习惯在项目中优先使用 mavenCentral()，如果公司有私有仓库，再加一个 maven { url '...' }。

// 仓库配置示例
repositories {
    // 公共仓库
    mavenCentral()
    // 或 jcenter() —— 不过它已经进入只读模式了，不建议新项目使用

    // 私有仓库（我在公司项目中经常这样配）
    maven {
        url = uri("https://nexus.company.com/repository/maven-public/")
        credentials {
            username = "admin"
            password = "password"
        }
    }

    // 本地仓库（调试时偶尔用）
    mavenLocal()

    // 也可以指定 Ivy 仓库
    ivy {
        url = uri("https://ivy.company.com/repo")
    }
}

10.2 依赖声明：用坐标精确锁定

依赖声明用的是「group:name:version」三段式坐标。但光有坐标还不够，你还得告诉 Gradle 这个依赖在哪个「配置」里生效。配置决定了依赖的作用范围——是编译时需要、运行时需要、还是测试时需要。

// 依赖声明示例
dependencies {
    // 编译和运行时都需要
    implementation 'com.google.guava:guava:31.1-jre'

    // 仅编译时需要，运行时由容器提供（比如 Servlet API）
    compileOnly 'javax.servlet:javax.servlet-api:4.0.1'

    // 仅运行时需要（比如数据库驱动）
    runtimeOnly 'mysql:mysql-connector-java:8.0.33'

    // 测试时使用
    testImplementation 'org.junit.jupiter:junit-jupiter:5.9.2'

    // API 依赖 —— 会暴露给消费者（多模块项目常用）
    api 'com.fasterxml.jackson.core:jackson-databind:2.14.2'
}

配置名称	作用范围	是否传递	典型场景
implementation	编译 + 运行时	不暴露给消费者	内部实现依赖
api	编译 + 运行时	暴露给消费者	公共接口依赖
compileOnly	仅编译	不传递	注解处理器、Servlet API
runtimeOnly	仅运行时	不传递	数据库驱动
testImplementation	测试编译 + 运行	不传递	JUnit、Mockito

10.3 依赖传递性：依赖的依赖

你声明了一个依赖，它自己可能还依赖别的库。这就是传递性依赖。Gradle 默认会帮你把传递性依赖也拉下来。听起来很方便，对吧？但有时候也会带来麻烦。

// 查看依赖树（终端执行）
// gradle dependencies --configuration compileClasspath

// 输出示例：
// compileClasspath
// +--- com.google.guava:guava:31.1-jre
//      +--- com.google.guava:failureaccess:1.0.1
//      +--- com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava
//      \--- org.checkerframework:checker-qual:3.12.0

你看，我只声明了 Guava，结果它把 failureaccess、listenablefuture、checker-qual 都带进来了。这就是传递性依赖的「连锁反应」。

我曾经遇到过一个坑：项目里同时引入了两个不同版本的 Log4j，结果运行时日志时有时无。排查了半天，才发现是传递性依赖搞的鬼。从那以后，我养成了定期跑 gradle dependencies 的习惯。

10.4 依赖冲突解决：谁说了算？

当同一个库出现多个版本时，Gradle 必须做出选择。它的默认策略很简单：选最新的那个。但「最新」不一定「最合适」，有时候你需要手动干预。

// 方式一：强制指定版本（我最常用的方式）
configurations.all {
    resolutionStrategy {
        force 'com.google.guava:guava:31.1-jre'
        force 'org.slf4j:slf4j-api:2.0.6'
    }
}

// 方式二：动态版本（慎用！）
implementation 'com.google.guava:guava:30.+'

// 方式三：版本锁定（Gradle 7.6+ 推荐）
implementation platform('com.example:my-bom:1.0.0')
implementation 'com.google.guava:guava'  // 版本由 BOM 决定

冲突解决策略	说明	适用场景
最新版本策略（默认）	自动选择依赖树中最高的版本	大多数情况
强制版本（force）	手动指定某个版本，覆盖所有传递依赖	安全漏洞修复、版本锁定
排除依赖（exclude）	从特定依赖中排除某个传递依赖	解决间接引入的不兼容库
BOM 平台	通过平台模块统一管理版本	多模块项目、微服务架构

10.5 实战：一个完整的依赖管理配置

把上面这些知识点串起来，一个典型的 Gradle 项目依赖配置大概长这样：

// build.gradle
repositories {
    mavenCentral()
    maven { url = uri("https://repo.spring.io/release") }
}

configurations.all {
    // 排除所有传递依赖中的旧版 commons-logging
    exclude group: 'commons-logging', module: 'commons-logging'

    resolutionStrategy {
        // 强制使用指定版本
        force 'ch.qos.logback:logback-classic:1.4.8'
        // 如果发现冲突，打印警告但不中断构建
        failOnVersionConflict()
    }
}

dependencies {
    // 核心框架
    implementation platform('org.springframework.boot:spring-boot-dependencies:3.1.0')
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'

    // 工具库
    implementation 'com.google.guava:guava:32.0.1-jre'
    implementation 'org.apache.commons:commons-lang3:3.12.0'

    // 数据库驱动
    runtimeOnly 'org.postgresql:postgresql:42.6.0'

    // 测试
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.9.2'

    // 编译期注解处理
    compileOnly 'org.projectlombok:lombok:1.18.28'
    annotationProcessor 'org.projectlombok:lombok:1.18.28'
}

嗯，这个配置基本覆盖了日常开发的大部分场景。你想想看，如果没有 Gradle 帮我们管理这些依赖，手动去下载 jar 包、处理版本冲突，那得多痛苦。

依赖管理看起来琐碎，但它是构建稳定性的基石。仓库配对了、依赖声明准确了、传递性控制好了、冲突解决了，你的构建才能又快又稳。说白了，这些功夫花在前期，后期就能少踩很多坑。

---

公众号:蓝海资料掘金营，微信deep3321