正则表达式如何捕获正前瞻（Positive Lookahead）匹配的分组

你无法捕获正前瞻内部分组内容的核心原因是：正前瞻（(?=...)）属于零宽度断言，它的作用仅为校验当前位置后方的内容是否符合规则，匹配过程不会消耗任何字符，绝大多数正则引擎不会将零宽度断言内部的分组作为有效捕获结果返回。你把需要捕获的尾部键: 值trailer内容完全放在正前瞻内部，自然无法拿到对应的匹配值。
另外原正则还有两个影响匹配的小问题：

• 正文匹配规则((?:\w|\s|\r|\n|\r\n)+)是贪婪匹配，没有做边界限制，容易吞掉本该属于尾部trailer的内容
• 换行符写法冗余，(\r|\n|\r\n)的分支顺序存在匹配优先级问题，跨系统兼容性差

把需要捕获的尾部trailer内容从正前瞻中移出，改为可选的普通捕获分组；正文匹配改为非贪婪模式，避免吞掉尾部内容；统一换行符匹配规则兼容Windows/macOS/Linux三种换行格式，修正后的正则如下：

^(?:(Initial commit)|(Merge [^\r\n]+)|((build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test|BREAKING CHANGE)(\(\w+\))?!?: ([\w ]+))(?:\r?\n|\r){0,2}([\w\s]*?)(?=(?:(?:\r?\n|\r){2}([\w-]+): (\w+))|$)(?:(?:\r?\n|\r){2}([\w-]+): (\w+))?)$

修正后各捕获组对应内容如下：

• 组1：匹配Initial commit初始化提交场景
• 组2：匹配Merge xxx合并提交场景
• 组3：常规提交的类型（如build/feat/fix等）
• 组4：提交的作用域（即括号内的内容，如示例中的Breaking）
• 组5：提交标题（即类型行冒号后的内容）
• 组6：提交正文内容
• 组7：尾部trailer的键（如示例#2中的asdf-asdf）
• 组8：尾部trailer的值（如示例#2中的asdf）

• 针对无尾部trailer的示例#1：组7、组8返回空值，其余分组可正常捕获标题、正文全部内容
• 针对有尾部trailer的示例#2：所有分组正常捕获，组7、组8可正确拿到trailer的键和值，不会出现内容丢失

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