semver，Semantic Versioning 语义化版本的缩写，文档可见 semver，它由 [major, minor, patch] 三部分组成，其中
major: 当你发了一个含有 Breaking Change 的 APIminor: 当你新增了一个向后兼容的功能时patch: 当你修复了一个向后兼容的 Bug 时对于 ~1.2.3 而言，它的版本号范围是 >=1.2.3 <1.3.0
对于 ^1.2.3 而言，它的版本号范围是 >=1.2.3 <2.0.0
npm package 通过 semver 进行版本管理。当我们下载 lodash 时，如果此时最新版本号为 lodash@4.17.4，则默认在 package.json 中维护的版本号为 lodash@^4.17.4。
在版本范围输入框中填写 semver 范围表达式，工具会解析并展示该范围匹配的版本区间。常用的范围语法包括：
^1.2.3：兼容补丁和次版本更新，匹配 >=1.2.3 <2.0.0~1.2.3：仅兼容补丁更新，匹配 >=1.2.3 <1.3.0>=1.0.0：大于等于指定版本1.0.0 - 2.0.0：闭区间范围>=1.0.0 <2.0.0：组合条件，用空格表示「且」^1.0.0 || ^2.0.0：用 || 表示「或」，匹配任一范围即可输入一个具体版本号和一个范围表达式，工具会告诉你该版本是否在范围内。这在排查依赖冲突时特别有用——你可以快速验证某个包的实际版本是否符合 package.json 中声明的约束。
工具会以直观的方式展示两个版本之间的关系。版本号由三部分组成：
预发布标签（如 1.0.0-beta.1）的优先级低于同版本的正式版。
{
"dependencies": {
"react": "^18.2.0",
"lodash": "~4.17.21",
"typescript": ">=5.0.0 <6.0.0"
}
}
^18.2.0 是 npm 默认行为，允许安装 18.x.x 的任意版本，但不会跳到 19.0.0~4.17.21 更保守，只接受 4.17.x 的补丁更新>=5.0.0 <6.0.0 显式写出范围，和 ^5.0.0 等价但更清晰当 npm install 报版本冲突时，把报错中涉及的版本号和范围粘贴到工具里，可以快速看出哪个范围无法兼容，从而决定是升级依赖还是调整范围。
发布前可以用工具验证：新版本号是否落在下游项目的依赖范围内。比如你要发 2.0.0，而下游写的是 ^1.5.0，那这次发布会导致下游无法自动升级，需要提前通知。
$ npm install semver
import { Range } from 'semver'
// >=1.2.3 <2.0.0-0
new Range('^1.2.3').range
^（caret）允许在不修改最左边非零版本号的前提下进行更新。例如 ^1.2.3 匹配 >=1.2.3 <2.0.0，允许 minor 和 patch 级别的更新。~（tilde）则更保守，仅允许 patch 级别的更新。例如 ~1.2.3 匹配 >=1.2.3 <1.3.0，只接受补丁版本变更。简单来说，^ 信任库作者遵循语义化版本规范（新功能向后兼容），~ 则只接受 bug 修复。
npm 默认使用 ^ 是为了在稳定性和灵活性之间取得平衡。精确版本锁定虽然最安全，但会导致依赖树中出现大量重复包，增大 node_modules 体积，也无法自动获取安全补丁。而 ^ 允许自动接收向后兼容的更新，包括 bug 修复和新功能，同时通过 package-lock.json 确保团队成员之间的版本一致性。这种策略假设库作者遵循 semver 规范，不会在 minor 版本中引入破坏性变更。
是的，这是 semver 中一个容易踩坑的地方。在 0.x.x 版本中，^ 的行为会发生变化：^0.2.3 匹配 >=0.2.3 <0.3.0，相当于 ~0.2.3，因为 0.x 阶段被视为不稳定版本，任何 minor 变更都可能包含破坏性修改。更极端的是 ^0.0.3 只匹配 0.0.3 本身。这意味着在使用 0.x 版本的库时，^ 并不像 1.x 以上那样宽松，需要特别留意。
有多种方式可以锁定版本。最简单的方法是在 package.json 中直接写精确版本号，如 "lodash": "4.17.21"，不加任何前缀。也可以使用 npm install --save-exact 或在 .npmrc 中设置 save-exact=true 来默认使用精确版本。此外，package-lock.json（npm）或 pnpm-lock.yaml（pnpm）会记录实际安装的精确版本，确保 CI/CD 和团队成员使用完全相同的依赖版本。建议将 lock 文件提交到版本控制中。
prerelease 版本的优先级低于对应的正式版本。例如 1.0.0-alpha.1 < 1.0.0-beta.1 < 1.0.0-rc.1 < 1.0.0。prerelease 标识符按照从左到右逐段比较：纯数字段按数值大小比较，字符串段按字典序比较，数字段的优先级低于字符串段。需要注意的是，在范围表达式中，^1.0.0 和 ~1.0.0 默认不会匹配到 1.1.0-beta.1 这样的 prerelease 版本，只有与范围中指定的 major.minor.patch 相同的 prerelease 才会被包含。