为何不含前瞻的正则Pattern2性能未优于含前瞻的Pattern1？

问题背景 #

需要匹配两类URL：

• 以/contactos或/contactos/结尾的URL
• 中间包含/gestao/的URL

最初编写了带负前瞻的Pattern1：

^(?:(?:/.+)+/contactos/?(?!.))|(?:(?:/.*)+/gestao(?:/.+))$

之后改为每个分支独立加首尾锚点、移除前瞻的Pattern2：

^(?:(?:/.+)+/contactos/?)$|^(?:(?:/.*)+/gestao(?:/.+))$

原本预期Pattern2性能更优，但.NET8基准测试显示：

• 匹配合规URL时，Pattern1略快
• 匹配不合规URL时，Pattern2稍好

疑惑该现象的原因，寻求解答。

原因分析 #

1. 合规URL匹配时Pattern1更快的核心原因 #

Pattern1的第一个分支用了负前瞻(?!.)，看似多了一步，但实际匹配合规的/contactos结尾URL时，正则引擎的匹配路径更短：

• 当引擎匹配到/contactos/?后，负前瞻(?!.)只需检查下一个字符是否不存在（即已到字符串末尾），这是零宽度断言，无需回溯，直接就能确认匹配完成。
• 而Pattern2的第一个分支是^(?:(?:/.+)+/contactos/?)$，引擎需要确认整个字符串的末尾刚好落在/contactos/?之后，虽然也是锚定，但$锚点在.NET引擎的默认实现中，需要结合前面的/.+做更严格的边界校验——尤其是当/.+匹配较长路径时，引擎可能会做少量回溯确认是否真的到了末尾，负前瞻的检查反而更直接。

另外，Pattern1的两个分支共享开头的^锚点，引擎启动时只需做一次开头锚定检查；而Pattern2是两个独立的^...$分支，引擎需要先尝试第一个分支的^，失败后再重新检查第二个分支的^——这步开销极小，但大量合规URL的匹配场景下，累积起来会让Pattern1略占优势。

2. 不合规URL匹配时Pattern2更优的原因 #

匹配不合规URL时，Pattern2的分支结构更清晰，引擎的失败回溯更少：

• Pattern1的第一个分支里有贪婪匹配的/.+加上负前瞻，当URL不符合结尾规则时，引擎会先尽可能匹配/.+，尝试匹配/contactos/?失败后，要回溯调整/.+的匹配长度，再加上负前瞻的检查，整个失败路径的步骤更多。
• Pattern2的第一个分支是^(?:(?:/.+)+/contactos/?)$，当URL不符合结尾规则时，引擎匹配到/.+后发现无法到达/contactos/?$，会更快终止第一个分支的尝试，转而尝试第二个分支；而且第二个分支的/.*虽为贪婪匹配，但有/gestao/.+的约束，失败时的回溯次数比Pattern1的对应分支更少——毕竟Pattern1的第二个分支共享开头锚点，引擎失败时的分支切换逻辑会多一些额外判断。

3. .NET正则引擎的实现细节影响 #

.NET的正则引擎基于NFA（非确定性有限自动机），对锚点、断言的处理有专属优化：

• 负前瞻(?!.)在.NET引擎中被优化为直接检查当前位置是否为字符串末尾，几乎无额外开销，甚至比$锚点的某些场景处理更快——因为$还需要考虑是否存在换行符等情况（默认模式下$匹配字符串末尾，但引擎内部判断逻辑比零宽度断言稍复杂）。
• 分支锚点共享与否，在.NET引擎的编译阶段有不同优化策略：Pattern1的共享^让引擎初始化时只做一次开头检查，而Pattern2的两个独立^分支，引擎需要为每个分支单独处理开头锚定，失败场景下这种重复检查的开销会显现出来。

内容的提问来源于stack exchange，提问作者Luis Abreu