4. 贪婪与惰性匹配：量词模式与性能影响
量词这东西，看着简单，用起来却容易翻车。我早年写过一个日志解析脚本，就因为在量词上偷了个懒，结果生产环境直接超时……后来排查发现，罪魁祸首就是贪婪匹配引发的灾难性回溯。
4.1 贪婪量词：默认的“拿得多”模式
正则默认是贪婪的。说白了，只要可能，它会尽量多匹配字符。
*—— 匹配0次或多次，尽量多取+—— 匹配1次或多次，尽量多取?—— 匹配0次或1次，优先取1次{n,m}—— 匹配n到m次，尽量取m次
举个例子：字符串 "aabab"，模式 a.*b。你猜它怎么匹配？它会先吃光所有字符，然后从末尾一个个吐出来，直到找到最后一个 b。结果匹配的是 "aabab" 整个串。
// 贪婪匹配示例
import re
text = "aabab"
pattern = r"a.*b"
match = re.search(pattern, text)
print(match.group()) # 输出: aabab
<.*>会匹配到最外层的整对标签，而不是你想要的单个标签。容易出错。
4.2 惰性量词：学会“够用就好”
惰性量词就是在量词后面加个问号。匹配策略刚好相反：能少取就少取，取到第一个满足条件就停。
| 贪婪写法 | 惰性写法 | 行为差异 |
|---|---|---|
* |
*? |
尽可能多 vs 尽可能少 |
+ |
+? |
至少1次，多取 vs 至少1次，少取 |
? |
?? |
优先1次 vs 优先0次 |
{n,m} |
{n,m}? |
取m次 vs 取n次 |
还用刚才的字符串 "aabab"，模式改成 a.*?b。它会从第一个 a 开始，每次只多取一个字符，发现 b 就立刻停下。所以匹配到 "aab"（第一组）。
// 惰性匹配示例
import re
text = "aabab"
pattern = r"a.*?b"
match = re.search(pattern, text)
print(match.group()) # 输出: aab
你想想看，如果源串特别长，贪婪的“吃多了再吐”会卡很久，惰性则边吃边看，遇到就停。
4.3 回溯机制：性能的隐形杀手
正则引擎在匹配失败时会“后悔”——退回到上一个决策点，尝试其他路径。这就是回溯。
我曾经在项目中遇到一个线上事故：一条正则 (a|aa|aaa)*b 去匹配几十KB的纯 a 字符串（没有 b）。匹配过程产生了指数级的回溯，直接导致CPU飙升500%。
为什么会这样？因为贪婪量词配合分支结构，每次回溯都会重新尝试所有分支可能性。最坏情况是 灾难性回溯。
(a+)+b）在失败时可能耗尽CPU。我建议：- 能用原子组
(?>...) 或固化分组的地方就用上，阻止回溯。- 优先使用惰性量词，除非你明确需要贪婪行为。
4.4 实战对比：什么时候该用什么
给你一张决策速查表，我平时写正则就靠它:
| 场景 | 推荐量词 | 理由 |
|---|---|---|
| 提取两个固定标记之间的最短内容 | 惰性 .*? |
避免跨过多余内容 |
| 匹配HTML标签属性值 | 惰性 ".*?" |
防止引号匹配越界 |
| 匹配包含多个分隔符的完整字段 | 贪婪 .* + 回溯控制 |
需要跨过中间子串，但要预判性能 |
| 验证邮箱/手机号等固定长度格式 | 具体数量 {m,n} |
不需要回溯，效率最高 |
| 去除多余空白（如多个空格变一个） | 贪婪 + |
一次性匹配所有连续空白，替换一次即可 |
来，我们看看回溯过程的直观对比。下面这张图展示了同一个字符串 "aab" 下，贪婪 a.*b 和惰性 a.*?b 的匹配路径差异。
从图上能直观看到：贪婪模式先吃光再吐，走了回头路；惰性模式边试探边走，发现目标就停。如果你要匹配的内容紧挨着起始标记，惰性一般更快。但如果目标在很远的地方，贪婪可能少走几步（因为它一口吞掉了很多中间字符，只需回溯几次）。
- 确定目标就在附近：用惰性
*?- 确定目标在很远：用贪婪
* + 具体边界锚定- 完全排除回溯：用原子组
(?>...) 或占有量词 *+（Python支持 *+ 和 ++ 需用 regex 模块）
嗯，到这里你应该能理解我为什么一开始说“量词看着简单，用起来容易翻车”了。下次写正则前，先问自己一句：我到底想让引擎多拿还是少拿？想清楚再下笔，性能就不会给你颜色看。