20.2 依赖版本管理：语义化版本、范围版本、锁文件机制

任何一个稍具规模的项目都会依赖数十甚至数百个第三方包，每个包又在不断发布新版本。如何在“享受最新特性与修复”和“保证项目稳定不崩”之间找到平衡，就是版本管理的核心命题。JavaScript 生态通过语义化版本、范围版本、锁文件这三层机制来解决这一问题。

20.2.1 语义化版本（Semantic Versioning，简称 semver）

语义化版本是一套约定俗成的版本号规则，格式为 主版本号.次版本号.修订号（例如 2.3.1），有时还会附加预发布标签（如 3.0.0-beta.1）。

• 主版本号（Major）：做了不兼容的 API 修改，升级后你的代码可能需要修改才能正常工作。
• 次版本号（Minor）：增加了向下兼容的新功能，不会破坏已有 API。
• 修订号（Patch）：做了向下兼容的问题修正，通常是 bug 修复，不影响 API。

举一个真实的例子：假设你项目里使用了 lodash@4.17.21。当 lodash 发布新版本时：

• 4.17.22 → 修订号升级，只是修复 bug，可放心升级。
• 4.18.0 → 次版本号升级，增加了新方法，但原有方法行为不变，可以升级。
• 5.0.0 → 主版本号升级，可能移除了某些函数或修改了函数签名，升级需谨慎并检查文档。

遵循 semver 的包，让开发者能从版本号上直接判断升级风险。但要注意：这只是一个美好的约定，并非强约束。现实中确实存在发布者不小心在次版本号升级中引入了破坏性变更的情况，因此关键依赖的升级仍需经过测试。

20.2.2 范围版本：package.json 中的 ^ 和 ~

在 package.json 中，你不会手动锁定一个精确版本（如 "lodash": "4.17.21"），因为这样会导致完全无法自动获取 bug 修复。通常你会指定一个版本范围，让包管理器在安装时自动选择合适的版本。

最常见的两个符号：

{
  "dependencies": {
    "package-a": "^1.2.3",
    "package-b": "~1.2.3"
  }
}

• ^（caret，插入符号）：允许安装兼容版本。规则大致是不改变最左边非零数字。

例如 ^1.2.3 会匹配 >=1.2.3 且 <2.0.0 的任何版本；^0.2.3 则匹配 >=0.2.3 且 <0.3.0（因为主版本为 0 时，次版本号的变动也可能造成破坏性变更）。

• ~（tilde，波浪符号）：更保守，只允许修订号变化。

例如 ~1.2.3 会匹配 >=1.2.3 且 <1.3.0 的版本。

• 精确版本：不写任何符号，如 "1.2.3"，表示只安装这一个精确版本（极少使用，因为无法自动获取修复包）。
• *通配符 或 x**：如 1.x 表示主版本号为 1 的任意版本，极度不推荐，因为引入的变动完全不可控。

实用建议：在项目依赖中，默认使用 ^ 可以让包管理器自动拉取次版本升级和修订修复，既获得新功能和 bug 修复，又降低破坏性风险。而对于一些对稳定性要求极高的依赖（如构建工具配置中的关键插件），可用 ~ 甚至精确版本锁定。

20.2.3 锁文件机制：让所有人装到一样的依赖

范围版本存在一个隐患：不同的时间执行 npm install，可能因为包发布了新版本，而导致安装的依赖树不完全相同。一个人能运行的项目，换一台机器后就崩溃，这种“在我机器上明明能跑”的悲剧正是锁文件要解决的问题。

当第一次安装依赖时，包管理器会生成一个锁文件，将整个依赖树精确锁定到具体版本，包括所有子依赖的版本：

• npm 生成 package-lock.json
• yarn 生成 yarn.lock
• pnpm 生成 pnpm-lock.yaml

锁文件会记录每个包的精确版本号和完整性校验值（哈希），甚至包括依赖的依赖的嵌套关系。后续任何人运行 npm install（或等价命令）时，如果有锁文件存在，包管理器会忽略 package.json 中的范围符号，直接安装锁文件中记录的精确版本。

重要规则：

• 锁文件必须提交到版本控制系统（Git），以确保团队环境和 CI/CD 环境的一致性。
• 当你在 package.json 中手动修改某个依赖的版本范围，或运行 npm install <package> 安装新包时，锁文件会自动更新。因此，任何锁文件的变更都应该被审阅。
• 如果出现依赖冲突或产生 bug，可以删除锁文件和 node_modules，重新安装生成一份“干净”的依赖树，这往往是解决奇怪问题的一剂良药。

20.2.4 三者协同工作流程

以开发中一个常见的场景为例，理解这三层如何配合：

1. 你在 package.json 中声明 "axios": "^1.6.0"。
2. 首次执行 npm install，npm 发现当前 axios 最新满足范围的是 1.6.7，于是安装它，并在锁文件中记录 axios@1.6.7。
3. 一个月后，axios 发布了 1.6.8（修复 bug），你的同事从仓库拉取代码，包含锁文件，执行 npm install，他也会安装锁文件中的 1.6.7，而不是最新的 1.6.8，保证环境完全一致。
4. 当你决定升级 axios，可以执行 npm install axios@latest，这条命令会更新 package.json 的范围，并重新解析版本，把锁文件中 axios 更新为 1.6.8。提交后，整个团队同步升级。

这样，package.json 记录开发者意图（想要什么范围的版本），锁文件记录当前实际安装的精确版本，两者各司其职，共同保障项目的稳定与可复现。理解并善用这层机制，是每个 JavaScript 开发者走向工程化的必修课。