---

title: 语义化版本 SemVer 解释 date: 2026-01-29 author: 霍玮放 description: semver, npm, engineering, standard

语义化版本 SemVer 解释

在软件开发中，依赖管理是一个极其复杂的问题。为了解决依赖地狱（Dependency Hell），Tom Preston-Werner（GitHub 联合创始人）提出了语义化版本控制（Semantic Versioning），简称 SemVer。

1. 版本号格式

SemVer 的核心是一个三位数的版本号格式：MAJOR.MINOR.PATCH（主版本号.次版本号.修订号）。例如：1.4.2。

其规则极其严格且明确：

1. MAJOR (主版本号)：当你做了不兼容的 API 修改。
   • 例如：删除了一个函数，或者改变了函数的参数定义，导致旧代码无法运行。
2. MINOR (次版本号)：当你做了向下兼容的功能性新增。
   • 例如：新增了一个方法，或者给现有方法增加了一个可选参数。旧代码依然能正常运行。
3. PATCH (修订号)：当你做了向下兼容的问题修正。
   • 例如：修复了一个 Bug，没有改变任何 API 接口。

此外，还可以在后面加上先行版本号（Pre-release），如 1.0.0-alpha.1。

2. npm 中的版本范围

在 package.json 中，我们通常不仅仅写一个固定的版本号，而是使用符号来指定一个“范围”。

常见的符号

• ^ (Caret): 允许次版本号和修订号变更（只要不改变最左边的非零数字）。
  • ^1.2.3 := >=1.2.3 <2.0.0
  • 用途：这是 npm install 的默认行为。它假设即使次版本更新，也不会破坏现有代码。
• ~ (Tilde): 允许修订号变更。
  • ~1.2.3 := >=1.2.3 <1.3.0
  • 用途：当你比较保守，只想要 Bug 修复，不想要新功能时使用。
• 指定版本: 1.2.3。
  • 用途：完全锁定，不允许任何变动。

为什么需要这些范围？

允许范围更新通过 npm update 可以让你的项目自动享受到开源库的 Bug 修复和新功能，而不需要每次手动修改 package.json。但这也是双刃剑，如果依赖包的作者没有严格遵守 SemVer（比如在 PATCH 版本里改了 API），就会导致你的项目突然崩溃。这就是为什么 package-lock.json 如此重要。