从文本和日志里做版本号提取:semver 提取与去重整理实战

整理一个依赖审计表的时候,我手里通常不是一份干净的列表,而是一堆 pnpm-lock.yaml 片段、CI 日志、更新记录和别人贴在工单里的零散信息。版本号散落在这些文本各处,有的写成 2.4.1,有的带着预发布后缀 1.0.0-rc.1,还有的干脆是个看着像版本却不合规的日期。手工挑出来再去重,既慢又容易漏。这篇文章讲怎么用语义化版本号提取器把这件事压缩成几秒钟。

什么是语义化版本号

语义化版本号(SemVer)的核心是主版本号.次版本号.修订号这三段数字,比如 2.4.1 里,主版本号是 2,次版本号是 4,修订号是 1。三段都必须是非负整数,中间用点号连接。在这之后可以接一个预发布标识,用连字符引出,比如 1.0.0-rc.1、3.2.0-beta.2、2.0.0-alpha。也可以再接构建元数据,用加号引出,比如 1.0.0+20130313144700。

提取器要做的判断,就是从一段任意文本里,只挑出符合这套规则的字符串。像 2024.10.3 这种四位年份开头的日期看着像版本,但它不符合规则,会被标成无效;残缺的 1.2 缺了修订号,同样无效。把这些误抓项保留下来并标记原因,反而能告诉你正则到底抓错了什么。

一段真实文本的提取结果

举个我常遇到的场景。把下面这段混着日志和说明的文本粘进去:

2026-01-12 build started for app@2.4.1
upgraded lodash from 4.17.20 to 4.17.21
release candidate cut: 3.0.0-rc.1
note: do not ship 1.2 (incomplete)
hotfix tag v2.4.1 re-applied
date stamp 2024.10.3 in footer

提取器扫完之后,输出大致是这样一张去重审计表:

| 原始值 | 规范化 | 行号 | 校验 | 原因 | |---|---|---|---|---| | 2.4.1 | 2.4.1 | 1 | 有效 | OK | | 4.17.20 | 4.17.20 | 2 | 有效 | OK | | 4.17.21 | 4.17.21 | 2 | 有效 | OK | | 3.0.0-rc.1 | 3.0.0-rc.1 | 3 | 有效(预发布) | OK | | 1.2 | — | 4 | 无效 | 缺修订号 | | 2024.10.3 | — | 6 | 无效 | 不符合 SemVer |

注意第 5 行的 v2.4.1 和第 1 行的 2.4.1 是同一个版本,开了去重之后只保留一条,行号会指回最先出现的位置。3.0.0-rc.1 带预发布后缀,会单独标出来,这样你做依赖审计时一眼就能看出哪些是正式发布、哪些还在候选阶段,不至于把 rc 版本误当成稳定版写进部署清单。

区分预发布版本为什么重要

预发布版本(alpha、beta、rc)的优先级低于对应的正式版本,1.0.0-rc.1 排在 1.0.0 之前。整理 changelog 或者写部署计划时,如果把这层区别抹掉,很容易出现"以为升到稳定版,实际锁了个候选版"的事故。提取器把预发布段单独识别并保留,排序时也按 SemVer 的优先级规则来,而不是简单的字符串比较,所以 1.0.0-rc.2 不会被错排到 1.0.0-rc.10 后面。

去重、排序和导出

抓全之后的事就轻量了。你可以只保留唯一行,把重复出现的同一版本折叠成一条;也可以把无效项一起带出来复核。排序按规范化后的值走,导出格式在逐行、CSV、JSON、Markdown、SQL IN 和 TypeScript union 之间随便切。要给脚本用就导 JSON,要塞进数据库查询就用 SQL IN,要写进类型定义就选 TypeScript union,省掉手工加引号和补逗号的活儿。

整个解析、校验、去重和导出都在浏览器本地完成,粘进去的依赖文件和日志不会发到服务器。如果你需要更专一的步骤,可以直接用语义化版本号去重器单做去重,用语义化版本号规范化器把 v2.4.1、2.04.1 这类写法统一,或者用语义化版本号校验器只跑合规检查。它们和提取器共用同一套引擎,流程能接起来。

一点提醒

从网页或工单复制来的文本经常夹着隐藏空白,导入前先规范化再去重,能避免同一个版本因为多了个空格被当成两条。另外校验通过只代表格式合规,不代表这个版本真的在仓库里发布过,做审计时这两件事要分开看。如果要留审计线索,别只复制最终列表,记得下载带行号的 CSV 或 Markdown,回头排查时能直接定位原文。

Made by Toolora · Updated 2026-06-13