3. 依赖管理优化：依赖解析策略、依赖缓存机制、依赖锁定与版本管理、减少依赖冲突

依赖管理，说白了就是管好你项目里的那些“外来户”。

我见过太多团队，构建一次花半小时，结果一半时间都在下载依赖。更糟的是，今天能编译通过，明天就挂了——就因为某个依赖偷偷升了个小版本。

这一章，咱们就把依赖管理这块硬骨头啃下来。

3.1 依赖解析策略：别让构建工具瞎猜

依赖解析，就是构建工具决定“到底该用哪个版本”的过程。不同的工具，策略完全不同。

策略	代表工具	核心逻辑	我踩过的坑
最近优先	Maven / Gradle	选择依赖树中距离根节点最近的版本	子模块偷偷引入旧版，覆盖了父模块的显式声明
深度优先	npm (v3+)	尽量将依赖扁平化到 node_modules 顶层	不同分支的同一个包版本冲突，导致“幽灵依赖”
锁定优先	Yarn / pnpm	严格遵循 lock 文件，不自行猜测	lock 文件冲突合并时，直接摆烂报错

核心原则：显式优于隐式。永远不要依赖构建工具的“智能猜测”。

我个人习惯在 Gradle 项目中，直接用 force 或 strictly 声明关键依赖的版本。比如：

// Gradle - 强制使用特定版本
implementation('com.google.guava:guava:30.1-jre') {
    version {
        strictly '30.1-jre'
        prefer '30.1-jre'
    }
}

// Maven - 在 dependencyManagement 里锁定
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>30.1-jre</version>
        </dependency>
    </dependencies>
</dependencyManagement>

注意：强制锁定版本是一把双刃剑。锁死了，可能和传递依赖的预期版本冲突，导致运行时 NoSuchMethodError。我曾经在一个微服务项目里，因为锁死了 Jackson 版本，结果三个子服务各用各的序列化特性，联调时直接崩了。

3.2 依赖缓存机制：把下载时间省下来

依赖缓存，是构建加速里性价比最高的优化之一。你想想看，同一个版本的 Guava，今天下载一次，明天 CI 又下载一次，这不是浪费生命吗？

常见的缓存策略分三级：

本地缓存：开发机上的 ~/.m2/repository 或 node_modules/.cache。默认就有，但容易被清理。
CI 缓存：在 Jenkins / GitHub Actions 里配置缓存目录。我建议把 ~/.gradle/caches 和 ~/.m2/repository 都缓存起来。
私有仓库缓存：搭建 Nexus 或 Artifactory 作为代理仓库。团队共用一份缓存，效果拔群。

我的经验：CI 缓存记得用 key 区分分支和构建号。否则，一个分支的缓存污染了另一个分支，你会 debug 到怀疑人生。

举个例子，GitHub Actions 里配置 Gradle 缓存：

- name: Cache Gradle packages
  uses: actions/cache@v3
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
    restore-keys: |
      ${{ runner.os }}-gradle-

嗯，这里要注意：hashFiles 只对构建脚本的变化敏感。如果你改了源码但没改依赖，缓存就能命中。第一次构建可能慢点，后续构建直接起飞。

3.3 依赖锁定与版本管理：锁死，别让它跑了

依赖锁定，就是给你的项目拍一张“全家福”——所有依赖的精确版本都记下来。

不同生态的锁定文件：

生态	锁定文件	生成命令	是否提交到 Git
Java (Maven)	无原生锁定文件，靠 `dependencyManagement`	手动维护	是
Java (Gradle)	`gradle.lockfile` (需插件)	`gradle dependencies --write-locks`	是
JavaScript (npm)	`package-lock.json`	`npm install` 自动生成	是
JavaScript (Yarn)	`yarn.lock`	`yarn install` 自动生成	是
Python (pip)	`requirements.txt` (需 `pip freeze`)	`pip freeze > requirements.txt`	是

铁律：锁定文件必须提交到版本控制。不提交锁定文件的团队，我遇到过不止一次——今天构建成功，明天因为某个依赖发了个新版本，直接炸了。

我个人习惯在 Gradle 项目里使用 gradle-lockfile 插件。配置很简单：

// build.gradle
plugins {
    id 'net.ltgt.gradle.lockfile' version '0.16.0'
}

// 生成锁定文件
// gradle dependencies --write-locks

// 验证锁定文件是否最新
// gradle dependencies --update-locks

锁定了之后，CI 里再加一步校验：如果锁定文件和实际解析结果不一致，直接让构建失败。这样，任何依赖变更都会被显式地审查。

3.4 减少依赖冲突：别让版本打架

依赖冲突，是构建加速的头号杀手。冲突了，构建工具就要花时间解析、排除、再解析。更可怕的是，冲突可能导致运行时诡异的问题。

常见的冲突场景：

传递依赖版本不一致：A 依赖 C 1.0，B 依赖 C 2.0。构建工具选了一个，另一个可能就炸了。
同一个依赖多个版本：classpath 里同时出现 guava-30.1.jar 和 guava-30.0.jar。JVM 加载哪个？看运气。
框架版本不兼容：Spring Boot 2.x 和 Spring Cloud Hoxton 混用，直接报错。

怎么治？我总结了三板斧：

统一版本管理：用 BOM（Bill of Materials）或版本目录（Version Catalog）。Gradle 7+ 原生支持 version-catalog。
主动排除：在声明依赖时，排除掉不需要的传递依赖。
依赖分析工具：用 gradle dependencies 或 mvn dependency:tree 查看冲突。

举个例子，Gradle 里排除冲突：

implementation('com.example:library-a:1.0') {
    exclude group: 'com.example', module: 'conflicting-lib'
}

// 或者全局排除
configurations.all {
    exclude group: 'commons-logging', module: 'commons-logging'
}

避坑指南：我曾经在一个大型 Java 项目里，因为排除了一个传递依赖，结果另一个模块的代码直接 NoClassDefFoundError。排除之前，一定要用 dependency:tree 看清楚谁依赖谁。别乱排。

3.5 知识体系总览

下面这张图，把依赖管理的核心逻辑串起来了。你可以把它当作一个检查清单。

依赖管理优化，不是一蹴而就的事。从解析策略开始，把缓存用好，锁文件提交到 Git，再定期用工具扫一遍冲突。每一步都能省下不少构建时间。

嗯，这一章的内容就到这里。记住：依赖管理做得好，构建加速事半功倍。

📚 课程目录

3. 依赖管理优化：依赖解析策略、依赖缓存机制、依赖锁定与版本管理、减少依赖冲突

3.1 依赖解析策略：别让构建工具瞎猜

3.2 依赖缓存机制：把下载时间省下来

3.3 依赖锁定与版本管理：锁死，别让它跑了

3.4 减少依赖冲突：别让版本打架

3.5 知识体系总览