.NET正则正向后行断言中贪婪子表达式为何产生多插入结果？

两类正则的引擎扫描逻辑完全不同，不存在等价关系，本质是「带字符消耗的贪婪匹配」和「纯零宽断言逐位扫描」的机制差异，而且这个行为完全符合.NET 正则的官方规范，只是因为开发者大多不熟悉可变宽度后顾断言的底层实现，初次遇到时会觉得意外。

普通消耗型替换的执行逻辑 #

我们先看第一组符合直觉的命令：

PS> 'a_b_c' -replace '^.+_', '$&|'
a_b_|c

这个写法里的^.+_是需要实际匹配、消耗字符的表达式：

• 因为.+是贪婪量词，引擎会从字符串开头启动匹配，一口气覆盖最长的可匹配子串——也就是从开头一直到最后一个下划线的全部内容a_b_。
• 匹配完成后，引擎会直接从这个最长匹配的结束位置继续向后扫描，不会回溯到之前的位置。
• 整个流程只会命中一个匹配点，因此替换时只在最长匹配的末尾插入|，得到符合预期的结果。

带后顾断言的替换的执行逻辑 #

再看第二组看似等价的命令：

PS> 'a_b_c' -replace '(?<=^.+_)', '|'
a_|b_|c

这个写法里的(?<=^.+_)是纯零宽正向后行断言，匹配过程不消耗任何字符，扫描逻辑和前者完全不同：

• 引擎的扫描规则是从字符串最左侧开始，逐位在字符间隙挪动，每停在一个间隙位置，就回头校验「这个位置紧贴前方的连续子串，能不能匹配括号里的^.+_表达式」。因为没有字符消耗，引擎永远不会跳过任何一个间隙位置。
• 关键实现细节：.NET 正则引擎校验可变宽度后顾断言时，只会用当前位置之前的字符串做匹配素材，完全看不到当前位置后方的内容。在当前位置的可用素材范围内，引擎会通过回溯找到所有可行的匹配方式——只要存在至少一种方式能让断言表达式成立，这个间隙位置就会被判定为有效匹配点。

逐位置拆解多次插入的来源 #

我们对原字符串a_b_c逐间隙校验，就能明白两次插入的逻辑：

1. 当引擎扫到第一个下划线和b之间的间隙时，当前位置前方的可用素材只有a_，完全看不到后面的b和第二个下划线。引擎先尝试把全部素材喂给贪婪的.+，发现后续匹配_时没有剩余字符，随即触发回溯：让.+只匹配字符a，剩下的下划线刚好匹配断言里的_规则，校验通过，在这里插入第一个|。
2. 引擎继续逐位后移到b和第二个下划线之间的间隙，此时前方的可用素材是a_b，最后一个字符是b，无论怎么回溯都无法匹配以下划线结尾的^.+_表达式，校验不通过，不做插入。
3. 引擎继续后移到第二个下划线和c之间的间隙，此时前方的可用素材是a_b_，可以轻松匹配^.+_（.+匹配a_b，末尾匹配下划线），校验通过，在这里插入第二个|。
   最终两次插入完成后，就得到了和直觉不符的结果a_|b_|c。

容易误解的点 #

很多开发者以为.+的贪婪性会在后顾匹配中一直延伸到字符串末尾，本质是忽略了两个核心机制：

• 零宽断言是逐位扫描的，每个位置做校验时，引擎的素材范围仅限当前位置前方的内容，看不到后续字符
• 正则的回溯机制会在有限素材范围内找到所有可行的匹配，不会因为贪婪就放弃短长度的匹配路径

网上常见的关于环视断言的通用讲解，大多只介绍「零宽、不消耗字符」的表层特性，很少提到可变宽度后顾在逐位扫描、回溯匹配时的具体行为，这也是很多人初次遇到这个场景会困惑的原因。

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