语义化版本控制（SemVer）：主版本、次版本、补丁版本规则及范围约束
说到依赖管理，版本号是绕不开的核心。我记得刚入行那会儿，看到同事写的 "^2.3.0" 一脸懵——这帽子符号是啥意思？后来自己踩坑几次才明白，版本号不是随便写的，它背后有一套“公约”，就是语义化版本控制（SemVer）。
说白了，SemVer 让开发者和工具能通过版本号判断兼容性。你不用看 ChangeLog，光看数字变化就知道升级风险有多大。
版本号长什么样？
标准格式是：主版本.次版本.补丁，比如 3.18.2。从左到右，三个数字分别代表：
- 主版本：做了不兼容的 API 修改。升级时，原有代码大概率要改。
- 次版本：新增了向后兼容的功能。升级后一般没啥问题，但记得测一下。
- 补丁：向后兼容的 bug 修复。闭眼升，基本安全。
我见过一个项目，依赖锁在 ^1.2.3，结果上游发了 2.0.0，CI 直接崩了——因为 ^ 不会自动上主版本。这就是 SemVer 的保护作用：你永远不用担心被大版本意外坑到。
| 版本变化 | 含义 | 升级风险 |
|---|---|---|
1.0.0 → 2.0.0 |
不兼容 API 改动 | 高，需要修改代码 |
1.0.0 → 1.1.0 |
新增功能，向后兼容 | 低，建议测试后升级 |
1.0.0 → 1.0.1 |
修复问题，无新功能 | 极低，可放心升级 |
范围约束：控制依赖版本
光有数字还不够。你在项目中需要告诉工具：“我要哪个范围”。常见的约束符号有 ^、~、>= 等。它们决定了你能接受的自动升级幅度。
^ 允许次版本和补丁版本变化，但锁定主版本。~ 只允许补丁变化，锁死主版本和次版本。
举个例子，你的 package.json 里写了：
{
"dependencies": {
"react": "^18.2.0",
"lodash": "~4.17.21"
}
}^18.2.0允许升级到18.3.0甚至18.99.999，但不会到19.0.0。~4.17.21只允许4.17.22、4.17.23这种补丁升级，不会到4.18.0。
我个人习惯是：核心依赖用 ^，让次版本的自然迭代能自动带来新特性；底层工具类用 ~（比如 lodash、moment），避免次版本引入非预期行为。我在项目中遇到过 moment 从 2.29.0 升到 2.30.0 时，时区处理逻辑变了，导致线上报告出 bug，如果当时用 ~2.29.0 就能避开这一劫。
"1.2.3" 没有前缀。当时以为最安全，结果安全更新来了也无法自动修复。后来 CI 扫描出低版本漏洞，还得手动一个个改。现在我的原则是：生产项目至少用 ~ 或 ^，别裸写版本号。
特殊场景：预发布版本和版本比较
SemVer 还支持预发布标签，比如 2.0.0-alpha.1、1.5.0-rc.3。这些版本在 npm install 时不会自动匹配，除非你明确指定。我有一个教训：团队用 ^1.0.0-rc.1 想锁住预发布版，结果正式版 1.0.0 发布后，^ 直接跳到正式版，代码直接崩——因为 rc 和正式版 API 不一致。正确的做法是固定版本号或使用 ~ 配合 tag。
版本比较规则也很简单：数字优先于字母，正式版优先于预发布版。1.0.0 > 1.0.0-rc.1。工具在解析范围时，默认忽略预发布版，除非用户特意声明。
知识结构一览
下面这张图帮大家理清思路：版本号怎么构成、范围约束怎么选、风险等级怎么判断。
为什么我一直强调要用范围约束？因为现实中的依赖树很复杂。你锁死了版本，子依赖却还在更新，最后 npm install 可能装出两套不同版本。用 ^ 或 ~ 配合 lock 文件，既灵活又可重复。
好了，这一节就聊这么多。你回去检查下自己的 package.json，看看有没有裸版本号——有的话赶紧改掉，别像我当年一样，等到安全警报响了才记得处理。