5.1 为什么需要包管理
前置知识：终端、Git 与调试器
预计时间：10 分钟
阅读方式：先认识角色，不在真实项目里安装依赖
完成标志：能区分包、仓库、包管理器、清单和缓存
开发环境已经有终端、Git 和调试器。新程序要解析 JSON，先检查标准库是否已经够用；确需额外能力时，再选维护状况和许可证适合的库。现成库也带来新问题：从哪下载、选哪个版本、它又依赖什么、团队如何复现。
五个对象，各管一件事
| 对象 | 作用 | 例子 |
|---|---|---|
| 包/构件 | 可发布和复用的代码单元 | Python distribution、npm package、JAR |
| 注册表/制品仓库 | 保存包与元数据 | PyPI、npm registry、Maven Central |
| 包管理器/解析器 | 选择并安装依赖 | pip、npm、Maven、Gradle |
| 项目清单 | 声明直接依赖和项目元数据 | pyproject.toml、package.json、pom.xml |
| 本地缓存 | 避免重复下载 | pip cache、~/.npm、~/.m2/repository |
缓存不等于清单，也不等于 lock。删除缓存可能触发重新下载，却不应改变项目声明。
三个生态的最小入口
下面只展示命令的形状，先不要在当前仓库执行。章末综合实验会创建临时目录，并明确哪些步骤可能联网。
Python 先创建虚拟环境：
bash
python3 -m venv .venv
. .venv/bin/activate
python -m pip --versionNode 项目先生成清单：
bash
npm init -y
npm install --package-lock-only --ignore-scriptsJava/Maven 在 pom.xml 声明坐标，再运行项目 Wrapper：
bash
./mvnw clean verify这些工具表面不同。pip 主要安装 Python 分发包；npm 同时维护清单与 lock；Maven 还执行编译、测试和打包生命周期。把它们全叫“下载器”会漏掉依赖解析与构建。
引入依赖前先问
- 包名和发布者是否可信，许可证是否适合项目？
- 维护状态、支持的运行时和平台是否满足需求？
- 依赖树、安装脚本和制品来源增加了什么风险？
- 项目如何锁定、升级、验证和移除它？
“不要重复造轮子”不是绝对规则。一个小函数可能比引入庞大依赖更容易审计；JSON、密码学、协议实现等边界复杂的功能则不适合随手自写。
离开这一页前
试着不看表格说清四句话：仓库在网络端保存包，清单属于项目，缓存属于机器，解析器根据约束构造依赖图。若把其中任意两个说成同一个东西，后面遇到安装失败时就很容易修错位置。