3、语义化版本控制（SemVer）：主版本号、次版本号、修订号的含义，版本范围指定（^、~、>=、<=），兼容性规则。
聊到包依赖，就绕不开一个基础概念——语义化版本控制，也就是大家常说的 SemVer。我个人觉得，这是整个依赖管理体系的基石。你想想看，如果没有一套统一的版本号规则，那包与包之间的兼容性就完全靠猜了，项目迟早会变成一团乱麻。
3.1 版本号的三个数字：主版本号、次版本号、修订号
SemVer 的格式很简单，就是 主版本号.次版本号.修订号，比如 2.5.1。这三个数字各有各的使命，不能乱用。
- 主版本号（Major）：当你做了不兼容的 API 修改时，就得加 1。说白了，就是「破而后立」。用户升级到这个版本，代码大概率要改。
- 次版本号（Minor）：当你以向后兼容的方式新增功能时，加 1。这意味着你可以放心升级，旧代码不会坏，还能用上新特性。
- 修订号（Patch）：当你做了向后兼容的问题修正时，加 1。通常就是修 bug、打补丁，对使用者来说最安全。
举个例子，1.0.0 是第一个正式版。如果后来加了个新功能但没破坏旧接口，就变成 1.1.0。如果修了个小 bug，就变成 1.0.1。但如果有一天你决定把某个接口的参数类型改了，那就得跳到 2.0.0。
核心原则：版本号不仅仅是数字，它是一份承诺。主版本号变了，意味着「你要小心了」；次版本号变了，意味着「有新东西来了」；修订号变了，意味着「更稳了」。
3.2 版本范围指定：^、~、>=、<=
在实际项目中，我们很少直接锁死一个版本号，而是指定一个范围。这样既能享受补丁更新，又不会因为大版本升级而翻车。常用的操作符有这几个：
| 操作符 | 含义 | 示例 | 匹配范围 |
|---|---|---|---|
^ |
允许次版本号和修订号升级 | ^1.2.3 |
>=1.2.3 且 <2.0.0 |
~ |
只允许修订号升级 | ~1.2.3 |
>=1.2.3 且 <1.3.0 |
>= |
大于等于某个版本 | >=1.2.0 |
>=1.2.0 |
<= |
小于等于某个版本 | <=2.0.0 |
<=2.0.0 |
我个人习惯，在项目里最常用的是 ^。为什么呢？因为它既保证了你能拿到次版本的新功能，又不会引入主版本的不兼容变更。比如 ^1.2.3，它会匹配 1.2.3 到 1.x.x 之间的所有版本，但绝不会跳到 2.0.0。
而 ~ 就更保守一些。我记得有一次，一个底层库的次版本升级引入了一个小 bug，虽然很快修复了，但那次之后，我对核心依赖就改用 ~ 了。只允许打补丁，心里踏实。
小技巧：如果你不确定用哪个，默认用 ^ 就好。对于测试框架、构建工具这类频繁更新的包，用 ^ 能让你及时获得改进。对于核心业务依赖，用 ~ 更稳妥。
3.3 兼容性规则：到底什么算「兼容」？
这个问题其实挺微妙的。SemVer 说「主版本号不同，不兼容」，但现实往往没那么简单。我遇到过好几次，一个库从 1.x 升到 2.0.0，只是删了一个废弃多年的函数，结果一堆项目就炸了。
所以，兼容性规则可以总结为以下几点：
- 主版本号变化：理论上不兼容。但实际中，有些改动对你是无感的。比如内部重构、性能优化，只要 API 没变，其实可以放心升。
- 次版本号变化：应该兼容。新增功能、弃用旧 API（但还没删），都不会破坏你的代码。
- 修订号变化：绝对兼容。只修 bug，不改行为。
嗯，这里要注意一点：「兼容」是单向的。也就是说，你的代码如果依赖 1.2.0 的某个行为，而 1.3.0 把这个行为改了（即使它认为这是 bug 修复），对你来说就是不兼容的。所以，别完全信任版本号，关键依赖还是要跑一遍测试。
避坑指南：我曾经在一个项目中，依赖了 ^0.8.0 的某个库。结果它从 0.8.5 升到 0.9.0 时，改了内部数据结构。因为 0.x 版本不承诺稳定性，所以这次升级完全合法，但我的代码就崩了。从那以后，我对 0.x 的包一律用 ~ 或者直接锁死版本。
3.4 知识体系图：SemVer 的核心逻辑
下面这张图，帮你把这一章的核心逻辑串起来。从版本号的三个数字，到范围指定，再到兼容性判断，一目了然。
说白了，SemVer 就是一套「君子协定」。它让包的发布者和使用者之间有了一个共同的沟通语言。你只要看到版本号，就能大概知道这次升级的风险有多大。但记住，规则是死的，项目是活的。关键依赖升级前，跑一遍测试永远是最保险的做法。