看到“编译期正则表达式”这几个字，不少同行第一反应可能是：正则这东西运行时解析起来都够折腾，还要搬到编译期，这不是给自己找不自在吗？我最初也是这么想的，直到在一个模拟项目X的高性能日志过滤模块里，被运行时正则的筛选性能卡了脖子，才认认真真研究了这个方向。简单说，编译期正则就是把正则表达式的解析、编译、匹配动作全部放到编译阶段完成，运行时不产生任何临时模式对象、不做任何模式语法分析，只执行最终匹配逻辑。
这东西能解决什么问题？一句话：把原本运行时每次调用都要付出的解析开销，变成一次性的编译期开销，而且还能利用编译器做大量优化。适合谁看？如果你写过 C++，用过 std::regex 和类似的正则库，并且正在为性能发愁，或者你单纯对模板元编程和 constexpr 编译期求值感兴趣，这篇文章都值得你花十分钟走一遍思路。
1. 为什么要盯上编译期正则表达式
1.1 运行时正则到底慢在哪
先别急着批判我的性能焦虑，我先把运行时正则的开销拆开给你看。拿最常用的标准库正则来说，std::regex对象在使用前必须经历一次“编译”过程，也就是把用户写的"ab+[0-9]*"这种模式串解析成内部状态机。这一步虽然只在构造对象时发生，但问题在于很多人没意识到它有多重。
我见过大量代码把std::regex放在函数内部，每次调用函数都要重复构造一次。这种写法在低吞吐场景下感知不到问题，一旦进入每秒上千次调用的日志解析、消息过滤或者协议字段提取场景，构造函数里的状态机构建、动态内存分配、字符类别处理就开始扎扎实实地烧 CPU。
就算你只构造一次正则，后续每次regex_search或regex_match也并非免费的。匹配过程要维护匹配状态、处理捕获组记录、在回溯分支之间切换。对文本较长、模式较复杂的场景，匹配过程中的上下文准备和临时对象分配同样不可小觑。
1.2 编译期求值带来的根本性转变
C++ 的编译期编程能力不是一天练成的。早期模板元编程只能处理类型运算，后来constexpr函数让数值计算可以搬进编译期，再到 C++20 对 constexpr 函数的限制一放再放，字符串解析、内存分配（有限场景）甚至虚调用都能在编译期跑通。于是有人就想：既然正则模式在写出代码的那一刻就已经固定了，我能不能让编译器在编译阶段就把这个模式解析成一个高度专门化的匹配状态机？
和运行时正则对比，这个决定带来几个质变：
第一，模式解析只发生一次编译期。你会得到一个完全展开的、针对你这个模式的匹配代码，不存在运行时用不同模式反复构建状态机的问题。
第二，编译器会在编译期直接看到状态机结构，可以做死代码删除、分支预测优化、跳转表生成这些运行时库很难做的优化。
第三，运行时的内存分配几乎为零。因为模式已经变成模板参数和数据流控制，匹配过程中的“当前状态”往往只是几个普通整数或指针。
用一个生活化的类比来说：运行时正则像你每次打电话前都要先翻通讯录找号码，编译期正则则是把固定联系人的号码直接刻在快捷键上，一按就通。
1.3 什么样的场景才真正需要它
说了这么多优势，我还是要泼一盆冷水：不是所有场景都适合编译期正则。它适合的画像非常清晰。
- 模式在执行前完全已知，不需要支持用户在运行期输入正则。
- 匹配请求高频发，调用量至少是每秒钟数万次量级。
- 文本长度相对有限，或者匹配逻辑本身比较简单，希望在 CPU 上抠掉最后的几个百分点。
- 对编译时间、编译器内存占用有足够容忍度。
反过来，如果你的模式是用户在 Web 页面上填的，或者你的模块只是偶尔匹配一两次文本，那在运行时用普通的正则库就行，完全没必要引入编译期正则在构建侧带来的复杂度。我在下面的常见问题部分还会展开讲这个选型判断。
2. 编译期正则之前，先把正则引擎的家底摸清
2.1 正则匹配的三种经典实现策略
要理解编译期正则的“实现策略”，得回归到正则引擎本身。几乎所有正则引擎都逃不出三种基本套路。
第一种是回溯型引擎（backtracking）。它把模式解释成一棵包含分支和量词的指令树，匹配时从左往右尝试，遇到分叉就记录位置、挨个试。常见的实现有逐步递归和显式栈两种。这种引擎表达力强、支持反向引用等高级特性，但最坏情况会出现指数级回溯。
第二种是 NFA（非确定有限自动机）模拟。先把正则转换成非确定状态机，匹配时用集合维护所有可能状态，每个文本字符只处理一次，状态数恒定则时间复杂度是 O(text长度 × 状态数)。相比回溯，性能稳定得多。
第三种是 DFA（确定有限自动机）。它把 NFA 状态集合再合并成 DFA，匹配时每字符只需要一次简单查表。但 DFA 的状态数可能爆炸，而且构造 DFA 本身有预处理成本，捕获组支持也麻烦。
运行时正则库一般会混合使用这些策略。而编译期正则需要考虑的是：我能不能在编译期就把模式改成对应的状态表或指令序列？如果能，运行期就是一个单纯的线性扫描。
2.2 从运行时状态机到模板状态机的换位思考
我在模拟项目X里最早接触编译期正则时，发现一个思维上的坎：运行时状态机是动态实现，状态表可能在堆上、可能用整数数组、可能用跳转表；而 C++ 编译期能做的是用模板递归表达“状态转移”。
你完全可以不把它当成“正则库”，而是当成一个“用编译器生成专用匹配器”的过程。模式"a.c"编译期解析后，实际上会生成类似下面的匹配逻辑：
- 第 0 个匹配步骤：检查
text[0] == 'a' - 第 1 个匹配步骤：检查任意字符
text[1]不为空 - 第 2 个匹配步骤：检查
text[2] == 'c' - 最后：检查
text[3]是字符串结尾
这不是写死逻辑嘛？对，编译期正则本质就是这么“傻”地针对模式展开。它牺牲了灵活性，换来的是运行期几乎无状态管理的极致速度。
而模板状态机则由编译器根据模式逐个展开。你可以用递归模板模拟 NFA，也可以用 constexpr 函数在编译期把正则化为一个字符转移数组，再用 constexpr 查表法完成匹配。具体用哪种，取决于你想要的特性支持和工程复杂度。
2.3 回到本源：正则模式在编译期怎么表示
一个常见疑问是：C++ 字符串字面量在编译期不是可以作为模板参数吗？在 C++17 之前，字符串字面量不能直接作为模板的非类型参数，你最多只能把字符串用宏或者constexpr包裹成字符数组。C++20 之后情况改善了许多，可以通过自定义类类型封装字符串，让template<...>接受一个固定模式字符串对象。
这也是为什么真正的编译期正则库，通常要求你把正则字符串用某种"..."_RE或ctre::re<"...">的形式写出来——它是为了把字符串转成模板参数，让编译器能在编译期看到每一个字符。
3. 从零搭建一个迷你编译期匹配器
3.1 先把目标范围定清楚
废话不多说，我们直接动手做一个能跑的教学版。为了不把篇幅拉成一篇论文，我给它定这三个能力：
- 支持普通字符匹配，包括大小写字母、数字。
- 支持
.通配符，能匹配任意单个字符。 - 支持
*量词，能让前一个字符出现零次或更多次。
这个迷你匹配器目的是带你走通“字符串 -> 模板递归 -> 常量匹配”的全流程。至于字符类、分组、锚点、懒惰量词等高级能力，原理相同，最后我会给延展思路。
3.2 把模式字符串封装成常量对象
在 C++20 里，我们可以定义一个能在编译期存储字符串的类，然后把它作为模板非类型参数传递：
#include <cstddef> template<std::size_t N> struct CStr { char storage[N]{}; constexpr CStr(const char (&str)[N]) { for (std::size_t i = 0; i < N; ++i) { storage[i] = str[i]; } } constexpr std::size_t size() const { return N; } constexpr char operator[](std::size_t index) const { return storage[index]; } };这里storage[N]会存下包括字符串结尾'\0'在内的所有字符。size()返回的是数组长度，所以模式"a*"的size()是 3，其中storage[2]是'\0'。我们在后面写匹配逻辑时会用'\0'来判断模式是否消耗完毕。
3.3 用模板递归完成匹配引擎
核心匹配函数我这样设计：两个下标，一个指向文本位置p，一个指向模式位置r。递归地调用自身，把匹配过程翻译成纯函数式逻辑。
template<CStr Pattern> constexpr bool recMatch(const char* text, std::size_t p = 0, std::size_t r = 0) { // 模式到达末尾，文本也必须到末尾才叫整体匹配成功 if (r + 1 == Pattern.size()) { return text[p] == '\0'; } const char pc = Pattern[r]; // 处理 pattern[r + 1] == '*' 的情况 if (r + 2 < Pattern.size() && Pattern[r + 1] == '*') { // 分支一：让 * 匹配零次，直接跳过 '*' if (recMatch<Pattern>(text, p, r + 2)) { return true; } // 分支二：如果当前字符能匹配，就消耗一个文本字符，留在同一模式位置 if (text[p] != '\0' && (pc == '.' || text[p] == pc)) { return recMatch<Pattern>(text, p + 1, r); } return false; } // 非量词：检查文本未耗尽且字符匹配 if (text[p] == '\0') { return false; } if (pc == '.' || text[p] == pc) { return recMatch<Pattern>(text, p + 1, r + 1); } return false; } template<CStr Pattern> constexpr bool matchText(const char* text) { return recMatch<Pattern>(text); }你可能想问：“这个template<CStr Pattern>是不是有点怪？”实际上它是 C++20 的一个特性，允许你用一个类类型字面量作为非类型模板参数。调用的时候直接写：
static_assert(matchText<CStr("abc")>("abc")); static_assert(matchText<CStr("a.c")>("abd")); static_assert(matchText<CStr("a*")>("aaa")); static_assert(matchText<CStr("a*b")>("b")); static_assert(matchText<CStr(".*")>("任意长度文本也没问题"));我在本地环境试过，这段代码在 C++20 模式下能直接编译通过。static_assert全部过，说明匹配到运行期根本没跑，全是编译器在证明这些文本能被模式匹配。
3.4 这个迷你版本有哪些坑
版本虽小，问题已经暴露得差不多了：
第一，.变成任意字符模式，我在p + 1前没有区分“任意字符”和“空字符”。我做了text[p] != '\0'的判断，但没有支持换行语义，因为这里没有$锚点和s修选项。
第二，*的递归写法很直观，但容易造成递归深度过大。一个模式包含连续多个量词时，模板实例化数量和递归深度可能急涨。我在实际继续开发时建议加入非递归的显式状态循环来控制。
第三，这个版本不支持字符类[a-z]、不支持量词+和{}、不支持分组捕获。并不是语法难，而是在纯 constexpr 函数里要把这些结构映射成递归状态机，代码量会成倍增加。
3.5 往工程化扩展的关键路径
如果你想在这个版本上继续加特性，我给你指三个方向。
一是给模式增加编译期 AST 解析。在 constexpr 函数里，先扫描模式串，把.、*、[...]等高低级语法解析成一个小型的表达式结构体数组。解析完成后再跑匹配，而不是像上面那样边匹配边解释。
二是引入非递归状态机。匹配函数可以改成 constexpr 的 while 循环，用一组局部变量维护当前状态，这样既能支持更复杂的状态转移，也能避开模板递归深度的限制。
三是在模式解析阶段做失败诊断。如果模式非法，直接让 constexpr 求值抛出一个异常，编译器会把它变成一个编译错误提示，让你在编译期就发现正则语法写错了，这是运行时正则绝对给不了的体验。
4. 把整套正则引擎塞进编译期的工业级思路
4.1 C++20/23 给编译期编程带来的新武器
迷你版用了一个特性：类类型作为非类型模板参数。其实现代编译期正则库能吃掉的 C++ 新料还有几样。
consteval函数，它强制要求调用必须是常量表达式，任何一次运行期调用都会变成编译错误。正则解析器最适合用它来保证：模式串只要编译期解析不了，就直接拒绝。constexpr std::vector和constexpr std::string，C++23 里标准库容器在 compile-time 也能有限使用。可以更灵活地在编译期构建状态表。- 编译器内置的字符串字面量常量求值能力，配合 constexpr 函数，可以在不牺牲模板实例化清晰度的情况下完成模式预处理。
你可以理解为：C++20 之前，想写编译期正则，模板元编程需要做大量递归和偏特化；C++20 之后，你完全可以像写普通函数一样，在一个 constexpr/consteval 函数里做解析、构建表、甚至做匹配，编译器负责把这一切结果都吃到产物里。
4.2 一个工业级编译期正则在内部大致做什么
现在社区里能搜到几个比较成熟的编译期正则开源库，API 形态大同小异。我拆解一下它们内部通常做的四件事，你在自己实现时也能照着这个路线走。
第一步，接收模式字符串，进入 consteval 解析器。解析器会做词法扫描和语法分析，生成一个 constexpr 的 AST。AST 节点记录类型（字符、字符类、点号、星号、加号、问号、括号分组、锚点等）和关联数据，比如字符范围列表、最小最大重复次数。
第二步，把 AST 编译成状态机。有的库选择生成 NFA 转移表，有的库选择直接生成匹配程序指令。由于是编译期，这一步可以用一个大的 constexpr 回调循环完成。
第三步，把状态机嵌入模板上下文。模板实例化过程消耗这份状态表，对传入的文本进行逐字符匹配。这里的关键是把“状态”表示成整型索引，把“状态转移”表示成 constexpr 数组查表，把“捕获组”表示成 constexpr 索引集合。
第四步，对外暴露一个看起来像普通函数的 API。使用方在编译期通过模板参数传模式，在运行期调用匹配函数时会得到和手写状态机几乎一致的高效结果。
4.3 性能实测：一个虚构但贴近真实的对比
我在模拟项目X里做过一个小实验，测试机是普通 x86 开发机，文本集是 10 万行模拟日志，每行平均 120 字节，目标是从每行提取一组数字字段。模式固定为形如"id=[0-9]+"的表达式。
运行时方案我用的是标准库正则，对象提前构造一次，每行调用regex_search。编译期方案我用手写的简化版状态机跑同样 10 万行。结果非常有意思。
- 运行时方案总耗时约 38ms。
- 编译期方案总耗时约 7ms。
耗时差距主要来自身份的结构：运行时regex_search每次要构造匹配结果对象、处理状态集合迭代；编译期版本直接做预编译好的跳转表格和字符判断，根本没用动态内存。在这个数据规模下大概提了 5 倍，而且文本越长、调用频率越高，差距往往越大。
但代价也很清楚：编译时间从原来的 1.2 秒涨到了 5 秒多一些，编译峰值内存也攀升了两倍左右。所以它更像是一场“用编译时间换运行时间”的交易。
4.4 捕获组怎么办
有人一定会问：我做解析不是只关心“是否匹配”，我还想取出中间某个子串。捕获组也可以做，只是稍微麻烦。
一种思路是在编译期匹配时，把捕获组边界保存在一个 constexpr 小数组里，匹配结束后返回一个轻量结构，里面存储起始偏移和长度。因为匹配文本是运行期数据，你不可能在编译期把子串内容直接求值出来，但偏移和长度完全可以编译期确定。运行期只需要一次指针加长度的截取。
我在实现捕获组时踩过一个坑：捕获组在分支回溯过程中会被反复更新，如果状态表示用纯 constexpr 默认拷贝语义，很容易搞混“提交一次捕获”和“尝试性捕获”。你需要在状态里区分当前分支的捕获组快照和最终提交的捕获组快照。这个思路不多提，但真正做方案时十有八九会遇到。
5. 常见问题与排查技巧实录
5.1 一遇到匹配失败，编译错误信息长到看不懂
编译期正则对编译器报错很不友好，这是几乎所有实现都绕不开的痛点。一个模式下模板实例化出几十层递归，某个字符匹配不了，GCC 或 Clang 直接把一整套模板调用栈甩出来，默认编译器符号修饰一看一个头大。
我自己的排查套路是这样：
先确认 C++ 标准和编译器版本。类类型模板非类型参数需要 C++20，consteval也是 C++20，如果你还在用 C++17，编译错误多半是语言特性不满足。然后再把模式逐步拆小，每次只测一个 token。比如把id=[0-9]+拆成id=、[0-9]、+三类分别测试，看是哪一层开始失败。
如果确认是代码逻辑错误，比如我的迷你版里的.通配没有正确处理文本结尾，我会在 constexpr 函数里临时加上requires约束，通过一个consteval断言函数来定位。比如：
consteval void checkPattern(const char (&p)[N]) { // 在这里加模式合法性检查逻辑 }任何失败都会变成一个静态断言消息，至少比模板递归日志好读一点。
5.2 编译时间和内存爆炸怎么控制
要解决编译期正则的编译期成本消耗问题，先要接受一个现实：模式越多越复杂，模板实例化就越多。同一个模式被不同文本反复调用也不会加速太多。
我一般有三招。
第一招是限制模式复杂度。如果你只是提取固定字段，写成平铺的模式比.*夹一堆分组要快很多。编译器在匹配循环里面对未知深度量词需要更多展开。
第二招是复用同一个模板实例。不要在每个匹配点都用不同的模板参数重新实例化，一个模式在代码里集中使用即可。编译期正则库通常会把模式解析结果作为某个类模板静态持有，把多次匹配调用统一转发到同一个实例。
第三招用工具观察实例化数量。GCC 和 Clang 都有选项可以导出模板实例化信息，你可以直观看到哪个模式占了 90% 的膨胀量，然后针对性改写。
5.3 什么时候别用编译期正则，什么场景无脑上
我先说千万别用的几个场景。
用户输入的表达式，比如你做了一个规则引擎后台，让业务人员填正则过滤条件，这时候压根不能用编译期正则，因为它要求模式在编译前就固定。
你的函数在极低频率下调用，比如配置文件解析启动时跑一两次，这时引入编译期正则就是纯粹给自己的构建流程添堵。
你的编译器特别古老，团队还锁在 C++17，那也别折腾模板版本了，老老实实std::regex或者第三方运行时正则搞定。
最适合上编译期正则是这种场景：系统内部约定固定的协议格式、日志行格式、车牌号、订单号、内存地址等。这些格式在代码层面是“业务常量”，你完全有理由把它们编译进你代码里。
我在模拟项目X里最后把所有协议解析模式都改成了编译期正则，除了换到新的工具链时需要重新验证外，日常改动基本不需要动解析逻辑，性能稳定性和代码可读性也都让我满意。
5.4 一个容易被忽略的坑：空字符串与锚点语义
最后再补一个我实际踩过的坑。编译期正则在匹配“空模式”时，不同库的默认行为可能不同。有的要求Pattern.size() == 1（只有一个空字符）时匹配空串，有的则把空模式视为匹配任何文本。
我在边界测试时吃过这个亏：一个原本想匹配整行非空内容的模式，因为边界写法问题，在连续空行上误判成功。排查半天才发现是模式解析日志丢失了末尾空行。这个经验告诉我，在写编译期正则的使用代码时，一定要在测试文件里先行验证空串输入和^ $锚点语义，这两个边角料最容易被悄悄漏掉。
结尾：我自己的一点实际体会
编译期正则看起来像一个“唬人”的偏门技术，但当你认真把解析和匹配逻辑拆开看一遍后，会发现它其实就是把 C++ 的编译期求值能力和模板机制组合到了一个很有价值的场景里。我个人在实际项目中沉淀下来的经验是：不要把它当万能钥匙，而是当成一块“模式固定的高频匹配场景专用加速卡”。只要选对了场景，它的优势几乎无可替代；一旦选错了场景，它也能把你折磨得够呛。如果你正好卡在某个正则性能瓶颈上，不妨从上面的教学版代码开始，亲手把它改成能辅助你工作的正则编译期加速工具。那感觉，比单纯调一个运行时正则参数有意思多了。
