在线正则表达式测试中的贪婪与懒惰匹配

用同一段文本观察三种匹配策略

在在线正则表达式测试中，量词的选择会直接改变匹配范围。用同一段文本、同一个正则引擎和同一组匹配选项，对比 <.*>、<.*?> 与占有量词，才能看清贪婪、懒惰和占有模式的差别。

准备样例文本：

<tag>A</tag>><tag>B</tag>

可以在 Regex101 中粘贴这段文本，并选择具体引擎测试。Regex101 的结果取决于所选正则引擎；同一个表达式在 PCRE2、JavaScript 和 Java 中不一定支持相同语法，也不一定产生完全相同的行为。

• 贪婪量词：默认尽可能多匹配字符，例如 *、+。
• 懒惰量词：优先尝试尽可能少匹配字符，例如 *?、+?。
• 占有量词：匹配后不主动回溯，例如 a++、a*+。

* 表示前一个元素重复 0 次至无限次，+ 表示重复 1 次至无限次，? 表示重复 0 次或 1 次。区间量词可写成 {m,n}，表示至少重复 m 次、至多重复 n 次；在某些写法中，? 还会改变前一个量词的匹配策略。

在相同引擎中运行三个表达式，通常会看到以下结果：

• <.*> 往往从第一个 < 匹配到最后一个 >，形成较长结果。
• <.*?> 通常停在第一个能够满足条件的 >，形成较短结果。
• 占有量词会禁止指定范围内的回溯，但具体结果取决于引擎是否支持这种语法。

这里的“通常”不能替换成“必然”。后续模式、换行选项、全局匹配设置以及正则引擎，都会影响最终结果。

贪婪量词为何会吞掉过多内容

表达式 <.*> 可以拆成三部分：先匹配 <，再让 .* 匹配任意字符，最后匹配 >。在默认贪婪模式下，.* 会先尽可能向后扩张，直到输入末尾附近，再检查最后的 > 是否能够满足表达式。

如果后续条件失败，引擎会退回已经匹配的字符，再尝试另一条路径，这个过程叫回溯。例如表达式后面还有固定文字时，.* 可能先吃掉过多内容，随后逐个退回字符，直到后续文字能够匹配。输入越长、分支越复杂，回溯搜索的成本越可能增加。

贪婪并不等于错误。如果任务就是寻找某个区域中最靠后的边界，贪婪量词可能正符合需求。但在提取标签、引号内容或日志字段时，直接使用 .* 往往把多个区域合并在一起。

更明确的写法是限制可匹配字符：

<[^>]*>

其中 [^>] 表示“不包含 > 的任意字符”。它不依赖懒惰量词去寻找边界，而是从字符集合层面排除结束符，因此在匹配简单、非嵌套标签时通常更容易理解和维护。若输入允许嵌套结构，正则表达式通常不是合适的完整解析工具，应使用对应格式的解析器。

懒惰量词如何停止在第一个边界

<.*?> 中的 *? 会让引擎先尝试匹配 0 个字符，然后逐步增加匹配长度；每增加一次，就检查后面的 > 是否成立。因此，在样例文本中，它通常会先得到 <tag>，接着在全局匹配开启时继续得到 </tag>、后面的标签等结果。

常见懒惰写法包括：

• *?：0 次至无限次，优先较短匹配。
• +?：1 次至无限次，优先较短匹配。
• ??：0 次或 1 次，优先选择 0 次。
• {m,n}?：在指定区间内优先较少重复。

懒惰只改变尝试顺序，并不是绝对的最短限制。如果结束条件不能立即成立，引擎仍会扩展匹配范围；如果结束条件过宽，结果也可能超出预期。例如 .*? 后面接一个可选条件，或者结束标记本身写得过于宽泛，懒惰量词仍可能回溯并覆盖较长文本。

可以按下面的步骤做对照测试：

1. 固定样例文本，不在每次测试时修改输入。
2. 在 Regex101 中选择同一个引擎，例如 PCRE2 10.x，并保持单行、忽略大小写等选项不变。
3. 分别运行 <.*>、<.*?> 和 <[^>]*>。
4. 打开全局匹配，检查每个完整匹配的起止范围。
5. 查看捕获组，再只替换量词，不同时改变其他表达式。

这样比较出来的差异才主要来自量词，而不是来自引擎或测试选项的变化。

占有模式与引擎差异决定最终行为

占有量词会在完成匹配后保留已经消耗的字符，不主动把它们交还给后续模式。例如 a++ 会尽可能匹配连续的 a，匹配完成后不因后续失败而回退部分字符。它通过减少搜索路径限制回溯，但也可能让原本能够成功的表达式直接失败。

原子组 (?>...) 有相近效果：组内匹配完成后，外部引擎不能回到该组内部尝试其他路径。两者都能限制特定范围内的回溯，但占有量词适用于单个量词，原子组可以包住一段更复杂的表达式。

• Java 8 及以上版本的正则能力支持占有量词和原子组。
• PCRE2 10.x 支持占有量词，具体行为仍取决于启用的语法模式和版本。
• JavaScript 原生正则不能直接照搬 a++ 或 (?>...)。
• Unicode Technical Standard #18 讨论了 Unicode 正则表达式相关技术，但它不负责统一所有语言引擎的扩展语法。

“懒惰一定返回最短文本，占有一定更快”都不准确。懒惰量词只是优先尝试较短候选，仍可能根据后续模式扩展和回溯；占有模式能减少回溯，但是否更快取决于引擎、输入长度、表达式结构以及失败发生的位置。

实际选择可以遵循三个判断：

• 需要在第一个明确结束符处停止时，先检查结束条件，再考虑懒惰量词。
• 能够准确列出允许字符时，优先使用字符类，例如 <[^>]*>。
• 确认存在大量无效回溯、且目标引擎支持时，再考虑 a++ 或原子组。

跨语言移植正则时，先确认目标引擎和版本，再确认占有量词、原子组、捕获组以及 Unicode 行为。在线测试的结果只能说明所选引擎下的行为，不能自动当成所有语言的通用规则。