我不想再盲贴正则表达式了: 从语法到 Scoop、Python、CMake、C++ 和 TypeScript

正则表达式到底是什么#

正则表达式不是一段会执行的业务代码，而是一种描述字符串集合的小语言。模式 cat 描述所有包含连续字符 cat 的文本；模式 ^cat$ 则只描述完整等于 cat 的文本。

我现在会把一次匹配拆成 4 个对象：

1. 目标文本：发布页、文件名、日志或源码。
2. 模式：哪些字符可以出现，以什么顺序出现。
3. 操作：搜索一处、搜索全部、验证全文、提取分组或替换。
4. 方言和宿主字符串：Python re、JavaScript RegExp、C++ ECMAScript、CMake Regex 和 .NET Regex 并不是同一个引擎，模式还可能先经过 Python、JSON 或 CMake 的字符串解析。

最后一项解释了大量 “明明在线网站能匹配，放进项目就坏了”。很多时候正则本身没错，错的是我拿法语词典去查西班牙语，或者字符串解析器先吃掉了一层反斜杠。

大多数本文涉及的引擎会从某个位置出发，沿着模式尝试字符，失败时再换分支或回退。我们可以把它想成一个在迷宫里移动的指针：普通字符是直路，| 是岔路，量词是可以重复走的环，回溯则是从死路退回来。这个比喻到这里就够了；真正重要的是，每增加一个含糊分支，引擎可能就多一条要探索的路。

先只学 6 组积木#

我不再从一张塞满符号的速查表开始。绝大多数日常模式都由下面 6 组积木拼出来。

1
release     -> 匹配 release
2
v2          -> 匹配 v2
3
x64         -> 匹配 x64

1
. ^ $ * + ? { } [ ] ( ) | \

1
2.7.3       -> 既能匹配 2.7.3，也可能匹配 2x7y3
2
2\.7\.3     -> 只把两个位置当作字面点号

1
输入: <a>one</a><b>two</b>
2
模式: <.*>
3
结果: <a>one</a><b>two</b>

1
模式: <.*?>
2
第一处结果: <a>

1
tool-v2.7.3-windows-x64.zip

1
tool-v2.7.3-windows-x64.zip.sha256

1
(windows|linux)

1
^cat|dog$      -> 以 cat 开头，或者以 dog 结尾
2
^(cat|dog)$    -> 全文只能是 cat 或 dog

1
模式: ^tool-v([0-9]+\.[0-9]+\.[0-9]+)-(windows|linux)$
2
输入: tool-v2.7.3-windows
3
组 0: tool-v2.7.3-windows
4
组 1: 2.7.3
5
组 2: windows

1
[0-9]+(?= MiB)       -> 只取 MiB 前面的数字
2
(?<=version=)[0-9.]+ -> 只取 version= 后面的数字
3
foo(?!bar)           -> foo 后面不能紧跟 bar

1
\b([A-Za-z]+)\s+\1\b

把一个版本模式从宽改窄#

我的实验页面抽取成纯文本后是这样：

1
Build date: 2026.09.07
2
Preview: v2.8.0-beta.1
3
Latest stable: v2.7.3
4
Requires Runtime 1.4.0

如果我只写：

1
[0-9]+(?:\.[0-9]+)+

Python 实际找到了 4 项：

1
['2026.09.07', '2.8.0', '2.7.3', '1.4.0']

模式没有错，它忠实找出了所有 “由点分隔的数字”。错的是需求只有 7 个字，“从页面提取版本”。页面上有 4 个都像版本的数字时，正则不可能读心。

我先把需求改写成人话：

找到以 Latest stable: 开头的完整行，允许冒号后有空白和一个 v，捕获恰好 3 段 ASCII 数字组成的稳定版号，不接受任何尾随字符。

然后逐块翻译：

1
^Latest stable:                锚定标签和行首
2
\s*                            允许 0 个或更多空白
3
v                              要求 v
4
([0-9]+\.[0-9]+\.[0-9]+)      捕获三段版本号
5
$                              到行尾必须结束

最终模式是：

1
^Latest stable:\s*v([0-9]+\.[0-9]+\.[0-9]+)$

加上多行模式后，它从 4 个候选收窄到 1 个，得到 2.7.3。这里不是正则突然变聪明了，而是我终于把上下文也写进了规格。

反斜杠为什么总像在繁殖#

屏幕上看到的模式经常要穿过两层语言：先由宿主语言生成字符串，再由正则引擎解释这个字符串。

我想交给正则引擎的内容是：

1
[0-9]+\.[0-9]+

在不同宿主里可能写成：

1
# Python raw string
2
pattern = r"[0-9]+\.[0-9]+"

1
// JavaScript 正则字面量
2
const pattern = /[0-9]+\.[0-9]+/;
3

4
// RegExp 构造函数还要经过字符串解析
5
const dynamicPattern = new RegExp("[0-9]+\\.[0-9]+");

1
// C++ raw string literal
2
const std::regex pattern{R"([0-9]+\.[0-9]+)"};
3

4
// 普通 C++ 字符串
5
const std::regex noisy{"[0-9]+\\.[0-9]+"};

1
{
2
  "regex": "[0-9]+\\.[0-9]+"
3
}

这几行最终送给引擎的是同一个模式。JSON 文件中的 \\ 不是正则需要两个反斜杠，而是 JSON 先把它还原为一个 \，正则再把 \. 解释为字面点号。

我现在调试这类问题时会打印宿主字符串的真实值，而不是盯着源码数斜杠。源码是包装盒，引擎收到的字符串才是货物。

Python: 把模式写成可执行规格#

Python 的 re 文档明确建议用 raw string 表示模式。我的完整实验如下：

1
import re
2

3
page = """Build date: 2026.09.07
4
Preview: v2.8.0-beta.1
5
Latest stable: v2.7.3
6
Requires Runtime 1.4.0
7
"""
8

9
loose = re.compile(r"[0-9]+(?:\.[0-9]+)+")
10
scoped = re.compile(
11
    r"^Latest stable:\s*v(?P<version>[0-9]+\.[0-9]+\.[0-9]+)$",
12
    re.MULTILINE,
13
)
14

15
print("loose:", loose.findall(page))
16

17
match = scoped.search(page)
18
if match is None:
19
    raise RuntimeError("stable version not found")
20

21
print("stable:", match.group("version"))

输出：

1
loose: ['2026.09.07', '2.8.0', '2.7.3', '1.4.0']
2
stable: 2.7.3

这里有 5 个常用 API，名字很像，但契约不同：

findall() 有一个容易忽略的行为：没有捕获组时返回完整匹配；有一个捕获组时返回该组；有多个捕获组时返回 Tuple。维护代码时，这种返回形状会因为加一个括号而变化。我需要稳定的详细结果时会用 finditer()，只用于结构的括号则写成 (?:...)。

替换也可以复用命名组：

1
versioned = "tool_2.7.3_windows.zip"
2
normalized = re.sub(
3
    r"^(?P<name>[a-z]+)_(?P<version>[0-9.]+)_(?P<os>[a-z]+)\.zip$",
4
    r"\g<name>-v\g<version>-\g<os>.zip",
5
    versioned,
6
)
7
assert normalized == "tool-v2.7.3-windows.zip"

1
artifact = re.compile(
2
    r"""
3
    ^tool-v
4
    (?P<version>[0-9]+\.[0-9]+\.[0-9]+)
5
    -(?P<os>windows|linux)
6
    -(?P<arch>x64|arm64)
7
    \.zip$
8
    """,
9
    re.VERBOSE,
10
)

Scoop: 从非 GitHub 页面提取稳定版#

GitHub Releases 可以让 Scoop 直接使用 "checkver": "github"。真正逼我写正则的，通常是厂商自己的下载页。

假设页面源码中有 3 个链接：

1
<a href="/downloads/tool-v2.8.0-beta.1-windows-x64.zip">Preview</a>
2
<a href="/downloads/tool-v2.7.3-windows-x64.zip">Latest stable</a>
3
<a href="/runtime/runtime-v1.4.0-windows-x64.zip">Runtime</a>

我的 Manifest 可以这样写：

1
{
2
  "version": "2.7.3",
3
  "homepage": "https://vendor.example/tool",
4
  "architecture": {
5
    "64bit": {
6
      "url": "https://vendor.example/downloads/tool-v2.7.3-windows-x64.zip",
7
      "hash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
8
    }
9
  },
10
  "checkver": {
11
    "url": "https://vendor.example/tool/downloads",
12
    "regex": "href=\"/downloads/tool-v(?<version>[0-9]+\\.[0-9]+\\.[0-9]+)-windows-x64\\.zip\""
13
  },
14
  "autoupdate": {
15
    "architecture": {
16
      "64bit": {
17
        "url": "https://vendor.example/downloads/tool-v$version-windows-x64.zip"
18
      }
19
    }
20
  }
21
}

这里我没有只抓 [\d.]+，而是把路径前缀、产品名、平台、架构和 .zip 后缀都放进模式。预览版因为版本后紧跟 -beta.1，无法满足 -windows；Runtime 又没有正确的路径和产品名。3 个链接只剩 1 个候选。

(?<version>...) 是命名捕获。Scoop 会把它作为版本使用，并能把其他命名组暴露成 $matchName 一类变量。官方的 Autoupdate 文档列出了 regex、replace、reverse 以及命名捕获的用法。

1
$page = Get-Content .\fixture.html -Raw
2
$pattern = 'href="/downloads/tool-v(?<version>[0-9]+\.[0-9]+\.[0-9]+)-windows-x64\.zip"'
3
$match = [regex]::Match($page, $pattern)
4

5
if (-not $match.Success) {
6
    throw 'stable version not found'
7
}
8

9
$match.Value
10
$match.Groups['version'].Value

1
href="/downloads/tool-v2.7.3-windows-x64.zip"
2
2.7.3

1
$checkver = "$(scoop prefix scoop)\bin\checkver.ps1"
2
& $checkver tool .\bucket
3
& $checkver tool .\bucket -Update
4
scoop install .\bucket\tool.json

CMake: 从第三方 Header 读取版本#

CMake 自己有一套较小的 Regex 方言。string(REGEX) 文档列出的核心能力包括锚点、点号、字符类、*、+、?、| 和捕获组。它没有列出 \d、{m,n}、非捕获组或 Lookaround，所以我不会把 Python 模式原样粘进去。

假设一个 vendored 第三方库只在 version.h 暴露版本：

1
#define MYLIB_VERSION_MAJOR 2
2
#define MYLIB_VERSION_MINOR 7
3
#define MYLIB_VERSION_PATCH 3
4
#define MYLIB_ABI_VERSION 4

我只筛选前三行，再取每行末尾数字：

1
file(STRINGS "${CMAKE_CURRENT_SOURCE_DIR}/vendor/mylib/version.h" version_lines
2
    REGEX [[^#define MYLIB_VERSION_(MAJOR|MINOR|PATCH) [0-9]+$]])
3

4
set(parts)
5
foreach(line IN LISTS version_lines)
6
    string(REGEX MATCH [[([0-9]+)$]] _ "${line}")
7
    list(APPEND parts "${CMAKE_MATCH_1}")
8
endforeach()
9

10
list(JOIN parts "." MYLIB_VERSION)
11

12
if(NOT MYLIB_VERSION MATCHES [[^[0-9]+\.[0-9]+\.[0-9]+$]])
13
    message(FATAL_ERROR "Cannot parse mylib version: ${MYLIB_VERSION}")
14
endif()
15

16
message(STATUS "MYLIB_VERSION=${MYLIB_VERSION}")

我实际用 CMake 4.1.6 运行了这段脚本，输出是：

1
-- MYLIB_VERSION=2.7.3

[[...]] 是 CMake Bracket Argument。它不处理反斜杠转义，因此模式里的 \. 可以原样到达正则引擎。若改用普通双引号，某些反斜杠还要经过 CMake 语言解析。CMake 官方文档也用 Bracket Argument 展示如何避免这层噪声。

这里还有两个边界：

1. CMAKE_MATCH_1 到 CMAKE_MATCH_9 保存捕获组，组数有限，而且没有命名捕获。
2. CMake 4.1 通过 Policy CMP0186 调整了重复搜索中 ^ 的行为。跨版本维护时，应该让 cmake_minimum_required() 明确策略范围，并针对项目最低版本验证。

1
file(GLOB sources CONFIGURE_DEPENDS "src/*.cpp")

vcpkg: 正则应该待在哪一层#

vcpkg Port 的 portfile.cmake 使用 CMake 语言，因此真要匹配文本时，面对的还是 CMake Regex 方言。但我不会让每次构建都抓网页，再用正则猜今天的最新版本。Port 构建需要可复现输入，“最新” 是一个会随时间移动的目标。

非 GitHub 上游通常使用 vcpkg_download_distfile()：

1
set(VERSION "2.7.3")
2

3
vcpkg_download_distfile(ARCHIVE
4
    URLS "https://vendor.example/releases/mylib-${VERSION}.tar.gz"
5
    FILENAME "mylib-${VERSION}.tar.gz"
6
    SHA512 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
7
)
8

9
vcpkg_extract_source_archive(
10
    SOURCE_PATH
11
    ARCHIVE "${ARCHIVE}"
12
)

这里的版本和 SHA512 都是固定输入。更新机器人或维护脚本可以在上游页面用正则发现 2.7.4，但它应该生成一次明确变更，重新计算哈希，经过审查后提交。构建阶段只消费已经确定的版本。

如果源码在 GitHub，优先使用 vcpkg_from_github()，并把 REF 固定到 Tag 或 Commit；官方文档也明确说 REF 不应是 Branch。正则适合发现候选版本，不适合替代依赖锁定。

C++: std::regex_search 和 std::regex_match 不是一回事#

C++11 在 <regex> 中提供了标准正则库。根据 cppreference 的正则库总览，std::regex 默认使用修改过的 ECMAScript Grammar，也可以显式选择 Basic、Extended、awk、grep 或 egrep 方言。

我用完整匹配验证发布物名称：

1
#include <iostream>
2
#include <regex>
3
#include <string>
4

5
int main() {
6
    static const std::regex artifact{
7
        R"(^tool-v([0-9]+\.[0-9]+\.[0-9]+)-(windows|linux)-(x64|arm64)\.zip$)",
8
        std::regex::ECMAScript
9
    };
10

11
    const std::string filename = "tool-v2.7.3-windows-x64.zip";
12
    std::smatch match;
13

14
    if (!std::regex_match(filename, match, artifact)) {
15
        std::cerr << "invalid artifact name\n";
16
        return 1;
17
    }
18

19
    std::cout << "version=" << match[1]
20
              << " os=" << match[2]
21
              << " arch=" << match[3] << '\n';
22
}

我用 GCC 15.3.0 编译运行，得到：

1
version=2.7.3 os=windows arch=x64

std::regex_match() 要求整个序列匹配，适合校验。std::regex_search() 只要求某个子序列匹配，适合从一段文本提取。即使模式已经有 ^ 和 $，我仍会选择表达意图的 API，让下一位读代码的人不用先审计两个锚点。

C++ 标准 Regex 没有命名捕获，所以 match[1]、match[2]、match[3] 的顺序就是接口。只用于结构的括号要尽量少；修改模式时，也要同步检查消费这些下标的代码。

std::regex 构造可能做明显多于字符串比较的工作。我不会在处理每一行的循环里重新构造同一个模式：

1
// 不要把固定模式放进热循环
2
for (const auto& line : lines) {
3
    std::regex pattern{R"(... )"};
4
    // ...
5
}
6

7
// 构造一次，重复使用
8
static const std::regex pattern{R"(... )"};
9
for (const auto& line : lines) {
10
    // std::regex_search(line, pattern)
11
}

如果需求只是判断固定前缀、后缀或单个分隔符，starts_with()、ends_with()、find()、from_chars() 往往更直接，也更容易得到稳定性能。正则是工具，不是加入项目后的强制税种。

JavaScript/TypeScript: 字面量、全局状态和动态模式#

JavaScript 中的正则是对象。MDN Regular Expressions Guide列出了两种构造方法：

1
// 固定模式，优先使用字面量
2
const fixed = /tool-v([0-9]+\.[0-9]+\.[0-9]+)/;
3

4
// 模式来自运行时数据时使用构造函数
5
const prefix = "tool";
6
const dynamic = new RegExp(`${prefix}-v([0-9]+\\.[0-9]+\\.[0-9]+)`);

构造函数接收字符串，所以 \. 要写成 \\.。如果变量可能包含 .、*、[ 等元字符，不能直接插值。现代运行时提供 RegExp.escape()：

1
const product = "tool.next";
2
const pattern = new RegExp(`^${RegExp.escape(product)}-v([0-9]+\\.[0-9]+\\.[0-9]+)$`);

RegExp.escape() 在较新的 JavaScript Runtime 中可用；项目的 Runtime 和 TypeScript lib 较旧时，要先核对兼容性，不要用手写的不完整替换冒充同等实现。

命名捕获让 TypeScript 端更清楚：

1
const page = `Build date: 2026.09.07
2
Preview: v2.8.0-beta.1
3
Latest stable: v2.7.3
4
Requires Runtime 1.4.0`;
5

6
const stable = /^Latest stable:\s*v(?<version>[0-9]+\.[0-9]+\.[0-9]+)$/m.exec(page);
7

8
if (!stable?.groups) {
9
  throw new Error("stable version not found");
10
}
11

12
console.log(stable.groups.version);

输出为：

1
2.7.3

常用 Flags：

1
const digits = /[0-9]+/g;
2

3
digits.test("v2"); // true, lastIndex 前进
4
digits.test("v2"); // false, 从上次位置继续

1
const digits = /[0-9]+/;
2
console.log(digits.test("v2"));
3
console.log(digits.test("v2"));

1
const text = "tool-v2.7.3 and runtime-v1.4.0";
2
const versions = [...text.matchAll(/v(?<version>[0-9]+\.[0-9]+\.[0-9]+)/g)]
3
  .map((match) => match.groups?.version);
4

5
console.log(versions); // ["2.7.3", "1.4.0"]

同一模式为什么不能到处复制#

我把本文几个环境放在一起：

“文档未定义” 不等于 “我的机器试了一次没报错，所以可以用”。可移植代码依赖的是目标方言承诺的语法，不是某次实现恰好接受的字符。

这也解释了在线测试网站的局限。它非常适合高亮匹配和观察分组，但我必须把 Flavor 设成真正的引擎。即便网站上看起来正确，最终测试仍要回到项目使用的 Python、Node.js、C++ 标准库、CMake 或 PowerShell。

我现在怎样从零写一个模式#

我把过去的 “AI 生成 -> 跑一下” 改成下面 7 步。

1
输入是发布页源码。
2
只接受 Latest stable 下载链接。
3
版本必须是 3 段 ASCII 数字。
4
拒绝 Preview、Runtime、校验和链接和其他架构。

1
应该接受:
2
tool-v2.7.3-windows-x64.zip
3
tool-v10.0.0-linux-arm64.zip
4
tool-v0.1.0-windows-arm64.zip
5
tool-v3.12.5-linux-x64.zip
6
tool-v1.0.0-windows-x64.zip
7
tool-v99.8.7-linux-arm64.zip
8

9
必须拒绝:
10
tool-v2.7-windows-x64.zip
11
tool-v2.7.3-macos-x64.zip
12
tool-v2.7.3-windows-riscv64.zip
13
prefix-tool-v2.7.3-windows-x64.zip
14
tool-v2.7.3-windows-x64.zip.sha256
15
tool-v2.7.3.4-linux-x64.zip

1
^tool-v-VERSION-(windows|linux)-(x64|arm64)\.zip$

1
[0-9]+\.[0-9]+\.[0-9]+

1
^tool-v([0-9]+\.[0-9]+\.[0-9]+)-(windows|linux)-(x64|arm64)\.zip$

1
import re
2

3
artifact = re.compile(
4
    r"^tool-v(?P<version>[0-9]+\.[0-9]+\.[0-9]+)-"
5
    r"(?P<os>windows|linux)-(?P<arch>x64|arm64)\.zip$"
6
)
7

8
cases = [
9
    ("tool-v2.7.3-windows-x64.zip", True),
10
    ("tool-v10.0.0-linux-arm64.zip", True),
11
    ("tool-v2.7-windows-x64.zip", False),
12
    ("tool-v2.7.3-macos-x64.zip", False),
13
    ("tool-v2.7.3-windows-x64.zip.sha256", False),
14
]
15

16
for text, expected in cases:
17
    actual = artifact.fullmatch(text) is not None
18
    assert actual == expected, text

AI 应该怎样参与#

我没有打算停止让 AI 帮我写正则。变化在于，我不再把输出当答案，而是当候选实现。

我现在会给 AI 这些材料：

1
目标引擎: .NET Regex，由 Scoop checkver 使用
2
宿主格式: JSON，所以反斜杠需要 JSON 转义
3
要提取: 命名组 version
4
正例: ...
5
负例: ...
6
要求: 解释每一段，不使用 Lookbehind
7
输出: 原始 Regex、JSON 字符串、PowerShell 验证脚本

然后我会反问 4 件事：

1. 哪个输入会被意外接受？
2. 哪个方言特性不可移植？
3. 模式交给引擎前的真实字符串是什么？
4. 是否存在不用正则的结构化方案？

AI 很擅长快速枚举语法，但它看不到我没有提供的页面变化，也不会自动知道这段字符串最终经过 JSON、CMake 还是 C++ Raw String。规格和反例仍然在我手里。

正则什么时候会变成第二个问题#

有些任务本身有明确语法树：HTML、JSON、XML、C++、URL。正则可以在局部定位文本，但通常不该承担完整解析。

我会在这些情况停下来：

• 需要处理任意层级嵌套，例如括号或 HTML Element。
• 输入已有成熟 Parser，例如 JSON、YAML、XML、URL。
• 模式开始依赖大量 .*? 跨越不受控内容。
• 每修一个负例就增加一条互相覆盖的 Lookaround。
• 输入来自不可信用户，而模式有嵌套、含糊的重复。

经典危险形状是：

1
^(a+)+$

对一长串 a 加一个结尾 !，某些回溯引擎会反复尝试把同一串 a 切成不同分组，组合数迅速增长。这类 ReDoS 不需要模式看起来很长，只需要路径足够含糊。

实用规则很朴素：避免在重复里再放可以用多种方式消费同一字符的重复；给输入长度设上限；不要让攻击者同时控制模式和超长文本；对外部输入做性能验证。若场景要求线性时间保证，可以考虑 RE2、Rust regex 这类限制部分高级能力以换取更可预测执行时间的引擎。

从今天往后#

我怀疑正则表达式短期内不会消失。结构化 API 会越来越多，但版本页、日志、构建输出、旧式 Header 和文件名仍然是一大片半结构化文本。模型会继续生成越来越像答案的模式，可真正的进步不是让我更快复制它，而是让我能读出 ^ 在约束什么、哪个括号在捕获什么、为什么 CMake 不接受 Python 的写法，以及负例会从哪条缝里钻进来。

这篇文章最后留下的不是一条万能正则，而是一套比较无聊但可靠的循环：写契约，收集正反例，选择方言，分块构造，在真实 Runtime 运行，再接入自动化。现在 AI 仍然可以写第一稿，只是那串线路噪声终于需要接受 Code Review 了。