语义化版本 解析与比较

什么是语义化版本解析器？#

语义化版本（SemVer）就是大多数库都在用的 主版本.次版本.修订号 约定，用它来表明一次发布包含的是哪一类改动：修 bug 升 patch，向下兼容地加新功能升 minor，带破坏性的改动升 major。再叠加预发布标识（1.0.0-beta.1）和构建元信息（+exp.sha.1），就得到了 semver.org 2.0.0 定义的完整语法。

麻烦在于，「比较两个版本」和「这个版本是否满足我的依赖范围」这两件事，靠肉眼很容易看错。1.0.0 比 1.0.0-beta 高还是低？（高——正式发布永远高于它的预发布。）1.2.3 满足 ^1.2.0 吗？（满足。）满足 ~1.2.0 吗？（也满足，但理由更窄。）本页按规范解析版本号、逐字段展示、按优先级比较两个版本，并用 package.json 里那套 ^ / ~ / >= / || / 连字符语法回答范围查询——全部本地运行，依据的是真实规则，而不是想当然。

如何使用#

1. 顶部的 快捷示例 按钮可以一键填入常见用例，你也可以直接输入。
2. 在两个输入框里分别填 版本 A 和 版本 B。开头带个 v 或 = 都能接受并被剥掉；1.2.3-beta.1+build.42 会被拆解成各组成部分。
3. 如果想做范围匹配，在 范围（range）里填入表达式。默认值是 ^1.2.0 || >=2.0.0 <3.0.0——两个用 || 连起来的集合，和真实依赖范围的写法一致。支持的语法有：^（caret）、~（tilde）、>= <= > < =、x / X / * 通配符、不完整版本号（1.2）、- 连字符范围，以及用 || 连接多个集合。
4. 阅读下方的两张 解析卡片。每张展示规范化后的 clean 形式，以及拆开的 主版本、次版本、修订号、预发布、构建 字段。非法版本会让卡片变红并给出提示。
5. 阅读 比较卡片。它会按优先级给出 A < B、A = B 或 A > B，并附上 diff——发生变化的最高位组件（主版本、次版本、修订号、预发布 或 构建）。
6. 阅读 范围检查卡片。针对你填的范围，它会告诉你 A 是否满足、B 是否满足。

主要特性#

• 按规范定优先级。 比较时依次走 major.minor.patch，再看预发布标识，遵循「不带预发布的版本永远高于带预发布的版本」这条规则。数字标识按数字比（beta.2 < beta.11），字母数字标识按字典序比，且数字永远低于字母数字。构建元信息会被解析和展示，但绝不参与优先级判定。
• caret 和 tilde 的正确展开。 ^1.2.3 展成 >=1.2.3 <2.0.0；^0.2.3 展成 >=0.2.3 <0.3.0；^0.0.3 展成 >=0.0.3 <0.0.4——遵循 caret 的「最左非零位」规则。tilde 则锁定同一次版本：~1.2.3 就是 >=1.2.3 <1.3.0。
• 支持 ||、连字符、通配符的范围。 ^1.0.0 || >=2.0.0 <3.0.0（两个集合取或）、1.2.0 - 1.5.0（闭区间连字符范围）、1.x / 1.2.*（通配符范围）都能解析和测试。
• 预发布纳入门槛。 一个预发布版本只有在「同一集合里存在某个比较器，且该比较器在相同的 major.minor.patch 上带有预发布标识」时，才可能满足范围。所以 1.5.0-rc.1 不满足 ^1.2.0，但满足 ^1.5.0-rc.0——这正是包管理器把来路不明的预发布挡在你的正式构建之外的做法。
• 能讲清故事的 diff。 diff 字段报告的是发生变化的最高位组件：从 1.2.3 跳到 2.0.0 显示 主版本；而 1.0.0 与 1.0.0 仅构建元信息不同时显示 构建，尽管优先级并未变化。
• 对输入宽容。 开头的 v、开头的 =、首尾空白都能容忍，所以从 git tag 或 changelog 里复制过来的版本号无需手动清理就能解析。

实战示例#

用默认值——A 1.2.3、B 2.0.0、范围 ^1.2.0 || >=2.0.0 <3.0.0——本页给出的结果是：

A clean    1.2.3        (major 1, minor 2, patch 3)
B clean    2.0.0        (major 2, minor 0, patch 0)
compare    1.2.3  <  2.0.0
diff       major
range      A satisfies   B satisfies

两个版本都满足范围，但理由不同：A 落在第一个或集合里（^1.2.0 → >=1.2.0 <2.0.0），B 落在第二个里（>=2.0.0 <3.0.0）。把 B 改成 3.0.0，它的徽标就会翻成 不满足——上界 <3.0.0 把它挡掉了。

想看清预发布规则，把 A 设成 1.5.0-rc.1、B 设成 1.5.0，范围保持 ^1.5.0-rc.0。此时 A 满足（同样是 1.5.0，且范围里带了匹配的预发布标识），而换成普通的 ^1.5.0 就不会让 1.5.0-rc.1 通过——这道门槛正是为了在你明确 opt-in 之前，把候选版本挡在正式的依赖解析之外。

常见问题#

1.0.0 比 1.0.0-beta 高吗？#

高。在相同的 major.minor.patch 下，不带预发布标识的版本永远高于带预发布标识的版本。所以 1.0.0 > 1.0.0-rc.1 > 1.0.0-beta.11 > 1.0.0-alpha。这也是为什么一次发布「正式定档」是一次真实的优先级跃迁，而不只是改了个标签。

^ 和 ~ 有什么区别？#

caret 允许那些不改变「最左非零位」的更新：^1.2.3 允许 1.x.x 中从 1.2.3 起到（但不包含）2.0.0 的任何版本。tilde 更严格——给定完整版本时锁定同一次版本：~1.2.3 只允许 1.2.x。只给主版本时（~1），tilde 和 caret 都放开整个主版本范围。大多数库用 ^ 锁定；自己发布的包打补丁时常会用到 ~。

为什么我的预发布版本不满足 ^1.0.0？#

这是设计使然。像 1.5.0-rc.1 这样的预发布，只有在「同一 AND 集合里某个比较器在同一个 1.5.0 上带了预发布标识」时才满足范围。^1.0.0 展开后是 >=1.0.0 <2.0.0-0，在 1.5.0 上没有预发布标识，所以这道门槛会把别人随手发的候选版本挡在你的正式构建之外。想主动放行，就显式写成 ^1.5.0-rc.0。

构建元信息会影响比较吗？#

不会。1.0.0+exp.sha.5 与 1.0.0+exp.sha.6 的优先级完全相等——构建元信息仅用于标识。解析器仍会把它展示出来（且仅元信息变化时 diff 会报 构建），但它永远不会左右顺序判定。