C++： std::regex 比 strstr 慢 100 倍?
前言
C++11 引入正则表达式库（<regex>）以来，关于它性能的争论就没停过。
有人测试后得出结论：“std::regex 比 strstr 慢上百倍”。
甚至不少人直接在项目中禁用了 <regex>，理由只有一个——“太慢了”。
但问题真有这么简单吗？
慢的背后，究竟是算法、实现，还是使用方式出了问题？
今天，我们不做情绪化的结论，只讲清楚几个事实。
一、std::regex 与 strstr，不是一个层级的工具
在讨论性能前，先得搞清楚这两个函数的出发点。
1. strstr 的定位
strstr 是一个非常古老的 C 库函数，它的作用很单纯：
在一段字符串中查找另一个字符串出现的位置。
const char* p = strstr("hello world", "world");它底层通常就是 O(n * m) 的匹配算法（不同实现会略有优化）。
这类函数的核心目标是：快。
输入是固定字符串，匹配的也是固定字符串。没有分支，没有复杂逻辑。
因此 strstr 本质上是“字符串搜索函数”，而不是“模式匹配引擎”。
2. std::regex 的定位
std::regex 是 C++11 提供的正则表达式引擎接口。
它实现了一个完整的模式匹配框架，语义上远比 strstr 复杂：
std::regex pattern("(\\w+)@(\\w+).com");
std::smatch match;
std::regex_search(text, match, pattern);
它能匹配分组、量词、字符集、环视、转义……
而这些功能的背后，是一个完整的正则解析、编译、执行模型。
换句话说，regex 并不是“字符串查找函数”，而是一个解释器。
如果把 strstr 比作“单一指令”，那么 std::regex 就像是“执行脚本的虚拟机”。
只是这种复杂度，用户往往看不到，于是就出现了“regex 比 strstr 慢百倍”的表象。
二、慢的真正原因：编译阶段的巨大开销
几乎所有抱怨 std::regex 慢的测试，都会写成这样：
auto start = clock();
for (int i = 0; i < 10000; ++i)std::regex_search(text, std::regex("abc"));
auto end = clock();
问题就出在这句：std::regex("abc")。
每一次循环都重新构造一个 std::regex 对象。
而 std::regex 的构造过程并不是分配内存那么简单——
它要经历整个“正则编译流程”：
解析字符串：把
"abc"拆分成 token。构建语法树：根据正则语法构造内部的 NFA（非确定有限状态自动机）。
优化与转译：部分实现会做模式简化或状态压缩。
生成执行状态机：为执行器准备匹配逻辑。
这一系列操作，在每次构造时都会发生。
而这些工作在 strstr 里根本不存在。
换句话说，很多人测试的其实是 “反复编译同一个正则的性能”，
而不是“正则匹配本身的性能”。
如果把编译阶段剔除，使用预编译好的 std::regex 对象，性能会大幅提升。
正确的用法应该是这样：
std::regex pattern("abc");
for (int i = 0; i < 10000; ++i)std::regex_search(text, pattern);
在这种写法下，std::regex 的慢才算进入“合理范畴”——
它确实不如纯字符串匹配快，但差距不会夸张到百倍。
三、算法层面：NFA 与 DFA 的取舍
正则匹配的底层算法，通常分为两种路线：
| 模型 | 特点 | 实现复杂度 | 性能表现 |
|---|---|---|---|
| NFA（非确定有限状态自动机） | 简单、灵活，支持回溯 | 实现简单，开销较高 | 速度中等偏慢 |
| DFA（确定有限状态自动机） | 不需要回溯，执行高效 | 状态数可能爆炸 | 速度快但内存大 |
C++ 标准库的 std::regex 默认使用 NFA 模型，而且是回溯式实现。
原因是：
它兼容性强，能完整支持所有正则语法。
不容易在状态构建阶段占用过多内存。
但问题也明显：NFA 的回溯在复杂表达式上非常耗时。
例如匹配 (a+)+b 这种嵌套量词，回溯路径会呈指数增长。
相反，像 re2（Google 的正则库）那样采用近似 DFA 模型的实现，
牺牲了一部分语法支持，却能在性能上遥遥领先。
所以慢并不是语言问题，而是“算法设计的选择”问题。
C++ 标准库选择了正确性优先，而不是性能优先。
四、C++ 标准库实现的尴尬现实
正则库的底层实现并非由标准指定，而是由编译器厂商完成。
这也意味着：不同平台的 std::regex 实现差距非常大。
1. libstdc++（GCC）
早期版本的 libstdc++ 使用的是 Boost.Regex 的移植版。
Boost.Regex 自身功能齐全，但性能并不出色。
主要原因有两个：
大量对象构造和内存分配；
复杂的状态管理机制。
这种实现导致简单的匹配操作也有不小的额外开销。
所以在 GCC 环境下，std::regex 给人的第一印象就是“慢”。
2. libc++（Clang）
Clang 的 libc++ 对正则部分做了部分重写，性能比 GCC 稍好。
但整体上仍然是以“标准兼容性”为优先目标。
3. MSVC STL
微软在 2015 之后的实现中引入了较多优化，
对常见模式的匹配路径进行了专门优化。
尽管如此，在复杂模式或频繁构造场景下，慢仍然明显。
换句话说，C++ 标准库的 regex 一直是“能用但不高效”的代名词。
这不是实现偷懒，而是受制于标准和兼容性。
五、关于编译成本的误解
很多性能测试文章都会把时间统计从构造到匹配全包进去。
这其实忽略了一个关键事实：正则编译是一次性成本。
std::regex 的设计理念是：
你定义一次模式，然后在大量文本上复用它。
标准库甚至提供了 std::regex_constants::optimize 标志，
告诉实现可以为后续匹配预先做优化。
std::regex pattern("abc.*def", std::regex::optimize);
这种优化可能包括状态表压缩、跳跃表构建等。
虽然构造会更慢，但多次匹配时性能反而更好。
如果你每次都重新 new 一个正则，那就完全背离了它的设计初衷。
这就像每次查找字符串前都重新初始化整个字典树，然后再查——当然慢。
六、复杂度的代价：功能与性能的权衡
性能差距的根本来源在于功能层级不同。
strstr 只能做一件事：查找固定子串。
regex 则要支持几乎整个正则语法体系。
比如 std::regex 需要处理以下问题：
转义字符处理（
\d,\s,\b等）分组与捕获
非贪婪匹配
零宽断言
Unicode 字符集兼容
多行模式 / 单行模式
回溯控制
匹配位置标记
这些逻辑意味着，在执行前必须先“理解”模式。
而理解的过程，就是解析、建树、生成状态机的过程。
这套机制带来的灵活性，是 strstr 无法比的。
同时也意味着，哪怕是一个最简单的 "abc"，regex 也要走完整个流程。
它不是“慢”，而是“复杂的必然代价”。
七、工程实践中的应对策略
明白原理之后，问题就简单了。
在工程中，我们并不是不能用正则，而是要用对场合。
1. 程序启动时预编译所有模式
如果匹配模式是固定的，把正则声明成 static 或成员变量。
不要在每次调用时重新构造。
static const std::regex pattern("(\\d{4})-(\\d{2})-(\\d{2})");
std::regex_match(str, match, pattern);
2. 简单匹配优先用字符串函数
判断前缀/后缀/子串出现位置，这类场景没必要上 regex。
C++17 提供的 std::string_view 与 starts_with、find 足够高效。
3. 对复杂匹配需求，可考虑替代实现
如果项目对性能有严格要求，可以引入专门的正则库，如：
RE2（Google）
Hyperscan（Intel）
PCRE2（Perl兼容正则）
它们在性能和安全性上都有成熟的工业级实现。
std::regex 适合一般性处理，但不适合大规模文本处理。
八、误解的根源：测试与期望的错位
很多性能争论，其实不是算法问题，而是期望问题。
期望
regex的性能像字符串函数；却又要它支持复杂的语法和语义。
当这种矛盾出现时，结果自然会让人失望。
更关键的是，很多测试方式本身就存在问题。
例如将构造时间算入匹配性能、将 debug 模式的结果拿去比较、
甚至把完全不同语义的函数放在同一个基准上。
这就好比用编译器速度来评判 CPU 性能——没意义。
九、结语：慢不是问题，不理解才是
回到最初的问题：
“C++ std::regex 比 strstr 慢 100 倍？”
如果你每次都重新构造一个正则对象，那可能慢上千倍；
如果你只编译一次再多次匹配，差距可能只有个位数；
如果你理解它的设计边界，你就不会再做这种对比。
std::regex 从来不是“查字符串的快刀”，
它是 C++ 标准库为复杂模式匹配提供的一把稳重的锤。
慢，不是它的缺陷，而是它背负的重量。