📚 课程目录第2章依赖管理基础

依赖管理基础：包管理器的工作原理与锁文件

依赖管理，说白了就是帮你管好「你的代码用了谁的代码」。我刚入行那会儿，项目依赖全靠人肉记，谁升级了谁没升级全靠猜。后来被坑了几次，才老老实实研究包管理器。今天咱们就聊聊 npm、pip、maven 这三兄弟，看看它们到底怎么干活。

包管理器的工作流程

不管哪个语言的包管理器，核心逻辑都差不多：

声明依赖：你在配置文件里写下需要什么包
解析依赖：管理器去查每个包又依赖了谁
下载安装：把整个依赖树拉下来放到本地
锁定版本：生成锁文件，保证下次安装一模一样

我见过不少团队跳过第4步，结果就是「我机器上能跑啊」——嗯，经典甩锅现场。

npm：JavaScript 的依赖丛林

npm 用 package.json 声明依赖，用 package-lock.json 锁定版本。它的依赖解析策略是嵌套的——每个包都有自己的 node_modules。

关键点：npm 的依赖树是真正的树，不是扁平化的。同一个包的不同版本可以共存。

举个例子：

// package.json
{
  "dependencies": {
    "express": "^4.18.0",
    "lodash": "^4.17.21"
  }
}

执行 npm install 后，npm 会：

解析 ^4.18.0 为 4.18.x 的最新版本
检查 express 的依赖（比如 body-parser、accepts 等）
递归解析所有传递性依赖
生成 package-lock.json 记录每个包的精确版本和下载地址

我个人习惯是：永远把 package-lock.json 提交到 Git。有一次项目紧急回滚，就是因为锁文件没提交，导致 CI 拉到了不同版本，线上直接崩了。

pip：Python 的依赖管理

pip 用 requirements.txt 管理依赖，但说实话，它早期版本对依赖树的处理比较粗糙。后来有了 pipenv 和 poetry，才真正有了锁文件的概念。

pip 的依赖解析是扁平化的——同一个包只能有一个版本存在。这就容易出问题：

# requirements.txt
requests==2.28.0
urllib3==1.26.0

如果 requests 依赖 urllib3>=1.26.2，那你的 1.26.0 就会被覆盖。pip 不会警告你，直接装最新的。

避坑指南：我曾经在生产环境遇到过 pip 静默升级依赖包，导致 urllib3 从 1.26.0 跳到 2.0.0，然后 requests 不兼容了。从那以后，我强制团队用 poetry 或者 pip freeze > requirements.txt 来锁定全量依赖。

Poetry 的锁文件 poetry.lock 就靠谱多了，它会记录每个依赖的精确版本、哈希值和依赖关系：

[[package]]
name = "requests"
version = "2.28.0"
dependencies = [
    {name = "urllib3", version = ">=1.26.2, <2.0.0"}
]

Maven：Java 世界的依赖仲裁

Maven 用 pom.xml 声明依赖，没有传统意义上的锁文件。它用的是「最近优先」策略——如果同一个包出现多个版本，选离根节点最近的。

<dependencies>
    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>30.1-jre</version>
    </dependency>
</dependencies>

Maven 的依赖树可以通过 mvn dependency:tree 查看：

[INFO] com.example:my-app:jar:1.0
[INFO] \- com.google.guava:guava:jar:30.1-jre:compile
[INFO]    \- com.google.guava:failureaccess:jar:1.0.1:compile

这里有个坑：如果两个依赖都引入了 guava，但版本不同，Maven 会选路径更短的那个。你想想看，这可能导致你代码里用的 API 在运行时不存在。

我的做法：在 pom.xml 里显式声明所有核心依赖的版本，用 <dependencyManagement> 统一管控。这样不管传递性依赖怎么折腾，最终版本都由你说了算。

传递性依赖：依赖的依赖

传递性依赖，说白了就是「你依赖的包，它自己也有依赖」。这是依赖管理的核心难点。

举个例子：

你的项目依赖 A v1.0
A v1.0 依赖 B v2.0
你的项目也直接依赖 B v1.5

这时候就冲突了。不同包管理器的处理方式不同：

包管理器	冲突策略	锁文件
npm	嵌套安装，各自用各自的版本	package-lock.json
pip	扁平安装，后安装的覆盖先安装的	poetry.lock / Pipfile.lock
Maven	最近优先，路径短的胜出	无（依赖由仲裁决定）

我记得有一次排查线上 bug，发现是 npm 嵌套安装导致同一个包的两个实例状态不同步。嗯，嵌套也有嵌套的烦恼。

锁文件的作用

锁文件的核心价值就一句话：保证可复现的构建。

没有锁文件，你周一装的依赖和周二装的依赖可能不一样——因为上游可能发布了新版本。锁文件把每个依赖的精确版本、哈希值、下载地址都记下来，确保每次安装都一模一样。

核心原则：锁文件必须提交到版本控制，并且永远不要手动修改它。

锁文件里通常包含：

每个包的精确版本号
包的完整性哈希（防止篡改）
依赖关系（谁依赖谁）
下载地址或 registry 信息

知识体系总览

下面这张图帮你理清本章的核心逻辑：

小结

依赖管理看着简单，但坑不少。记住几个要点：

锁文件必须提交，这是底线
理解传递性依赖，别等冲突了才去查
不同包管理器策略不同，别拿 npm 的经验套 Maven
定期审视依赖树，去掉没用的包