用正则处理大文本时有多慢？实测后我换了状态机解析

上周帮同事排查一个日志分析服务，一个 2.3GB 的 Nginx access log，用正则逐行提取 IP、时间、URL、状态码，跑了一分半还没结束，内存还飙到 4GB。我接手后把核心解析换成手写状态机，同样的文件 8 秒跑完，峰值内存不到 200MB。

这件事让我重新认真看了看“正则处理大文本”这件事。结论先说：正则不是慢，而是在大文本、逐行、复杂分组的场景下，它的固有成本会被放大到难以接受。如果你的解析逻辑固定、数据量又大，状态机几乎是更划算的选择。

正则到底慢在哪

正则引擎大致分 DFA 和 NFA，大多数语言默认是回溯型 NFA。简单模式还好，一旦出现交替、量词嵌套、贪婪匹配，就可能指数级回溯。日志解析里常见的 `(?:\d{1,3}\.){3}\d{1,3}` 这种 IP 模式，单看没问题，但和后面的可选分组组合起来，引擎会反复试错。

另一个容易被忽略的成本是逐行调用。`re.match` 每次都要走一遍正则虚拟机，字符串切片、分组捕获对象创建都有开销。2GB 文本、两千多万行，哪怕每行只花 5 微秒，也 100 秒了。

实测数据

测试环境：Python 3.12，Linux x86_64，文件 2.3GB、约 2100 万行。

方案 A：正则。

pat = re.compile(r'^(?P<ip>\d+\.\d+\.\d+\.\d+) .*?"(?P<method>\w+) (?P<url>[^ ]+) .*?" (?P<status>\d{3})')
for line in f:
    m = pat.match(line)

耗时 143 秒，峰值内存 3.7GB。

方案 B：状态机逐字符扫描。一次遍历，遇到空格或引号切换状态，直接切出字段。耗时 9.4 秒，峰值内存 180MB。差距 15 倍。

如果换成 Go 的 `regexp` 和手写 scanner，差距也类似：22 秒 vs 1.6 秒。这说明问题不在 Python 的 C 实现，而在正则这套匹配模型本身。

状态机怎么写

不用想得太复杂。以 Nginx 日志为例，字段之间用空格分隔，URL 和 UA 里有引号，所以状态就几个：找 IP、跳过分隔符、读方法、读 URL、读状态码。伪代码大概是这样：

state := stateIP
for i := 0; i < len(line); i++ {
    c := line[i]
    switch state {
    case stateIP:
        if c == ' ' { state = stateSkip; /* 记录字段结尾 */ }
    // ...
    }
}

关键是三点：不回溯、不建临时字符串、不生成捕获组对象。只记录字段起止下标，需要时再 `line[start:end]`。这样既快又省内存。

什么时候还该用正则

不是说正则一无是处。配置解析、一次性小文本、复杂但低频的校验，正则仍然是表达效率最高的方式。问题在于：把正则用在热路径上、处理 GB 级文本、还带复杂分组和回溯。

我的判断标准很简单：

- 文本小于 10MB、调用频率低：正则随便用。
- 文本大、逐行处理、模式固定：状态机或字符串切分。
- 模式复杂且会变：先测性能，再决定要不要手写。

总结

这次替换让我重新理解了“正则慢”不是玄学，而是回溯引擎和逐行调用的固有成本。大文本解析场景下，手写状态机没有想象中难，收益却非常直接。下次再遇到正则卡住，不妨先跑个 profile，再考虑换状态机。