为何可选零宽捕获组中的前瞻断言会阻止该组匹配？

你遇到的这个问题确实挺绕的，我刚接触正则的时候也被类似的现象搞懵过，咱们一步步拆解来看就清楚了。

首先看第一个正则/(^.)?/，逻辑很直白：尝试匹配字符串开头的任意单个字符，整个分组是可选的（末尾的?）。匹配'ab'时，开头的'a'完美符合^.的规则，所以分组成功捕获到'a'，返回的数组里第一个元素是整体匹配结果'a'，第二个是分组捕获的'a'，这部分没啥问题。

重点来了，第二个正则/(^(?=.))?/为什么会返回["", undefined]呢？核心在于前瞻断言的「零宽度」特性——它只负责检查当前位置后面的字符是否符合条件，本身不会消耗任何字符，也不会捕获内容。

咱们拆解这个正则的匹配过程：

• 最外层的(...)？表示这个分组是可选的，匹配引擎可以选择匹配这个分组，也可以选择不匹配。
• 分组内部的^(?=.)：^先定位到字符串开头，然后(?=.)检查开头后面有没有至少一个字符（对'ab'来说，这个检查肯定是成立的）。但注意，这个断言只是做了个「确认」，既没移动匹配指针，也没抓取任何字符。

那问题就出在这个分组的匹配结果上：(^(?=.))这个分组本身能匹配到什么？因为里面的前瞻不消耗字符，^只是定位位置，所以这个分组实际上匹配的是空字符串。但为什么加上?之后，分组就变成未匹配（undefined）了？

你可以先测试一下去掉?的情况：'ab'.match(/(^(?=.))/)会返回["", ""]，这说明分组确实能捕获到空字符串。那加上?之后为啥不一样？

原因在于正则引擎的匹配优先级：当可选分组的「匹配」和「不匹配」两种路径，最终得到的整体匹配结果完全相同（都是空字符串）时，引擎会优先选择「不匹配分组」的路径。简单说就是，既然两种选择都能得到一样的整体结果，那引擎就会选那个「更少捕获」的选项，所以分组就变成了未匹配状态，返回undefined。

换句话说，你原本预期分组能捕获到空字符串，但引擎觉得：“反正匹配不匹配这个分组，整体都是空字符串，那不如不匹配这个分组省事”，于是就出现了你看到的结果。

内容的提问来源于stack exchange，提问作者Aran-Fey