量词仅作用于紧邻前一个元素，需用()显式分组；带量词的捕获组只保留最后一次匹配；嵌套量词易引发回溯爆炸，应优先使用非捕获组或拆解逻辑。

正则表达式中量词（如 *、+、{n,m}）与分组（()）嵌套时，极易产生逻辑偏差、匹配结果出人意料，甚至引发严重性能问题。关键不在于“能不能写”，而在于“是否理解其实际行为”。

量词只作用于紧邻的前一个元素

这是最常被忽略的基础规则。量词不会自动“包裹”整个分组意图，除非你显式用括号界定范围。

• 错误写法：a+b+ —— 它匹配的是“一个或多个 a”，后接“一个或多个 b”，如 aaabbb；但若本意是“ab 整体重复多次”，这就不对
• 错误写法：\d+\.\d+ 用于匹配 123.456.789？不行——它只会匹配 123.456，因为 + 只管前面的 \d 和 \. 各自，不控制整体结构
• 正确写法：要匹配“ab 重复多次”，必须写成 (ab)+；要匹配“带小数点的数字序列”，应写成 (\d+\.)+\d+ 或更稳妥的 \d+(?:\.\d+)*

带量词的捕获组只保留最后一次匹配

当分组外接量词（如 (\w+)+ 或 (\d{2},?)+），该分组在匹配过程中会反复覆盖，最终 $1 或 group(1) 只存最后一次成功捕获的内容。

• 例如：re.search(r'(\d{2},?)+', '12,34,56') 中，group(1) 是 '56'，不是 '12' 或全部
• 若需提取所有项，应改用 findall 配合无量词分组：re.findall(r'\d{2}', '12,34,56') → ['12','34','56']
• 命名组也无法改变这一行为：(?P<num>\d{2})+</num> 同样只保留末次值

嵌套分组 + 嵌套量词 = 回溯爆炸风险

像 (a+)+、((\w+\.)*\w+)+ 这类结构，在面对模糊或失败匹配时，引擎会尝试海量回溯路径，导致 CPU 占用飙升、响应卡死，尤其在长文本中。

• 典型症状：正则在某些输入下秒出结果，换一个相似字符串却卡住几秒甚至超时
• 规避方式：优先使用非捕获组 (?:...) 减少捕获开销；用原子组 (?>...)（PCRE/PHP/Perl 支持）或占有量词 ++、*+ 阻止无效回溯
• 更优替代：把嵌套逻辑拆解为多步处理，或改用更明确的模式，例如用 [^\s,]+ 替代试图用 (\w+[, ]*)+ 匹配逗号分隔列表

非捕获组不是可有可无的装饰

写 (...) 默认就是捕获组，哪怕你根本不用它的内容。过多捕获不仅拖慢速度，还会干扰分组编号，让 $2、group(3) 等引用难以追踪。

• 只要分组仅用于逻辑分组或应用量词，就该用 (?:...) 明确声明“不捕获”
• 对比：(https?|ftp)://(\w+\.)+\w+ 有 2 个捕获组；而 (?:https?|ftp)://(?:\w+\.)+\w+ 仅 0 个，更轻量且意图清晰
• VSCode、JavaScript 等环境对捕获组数量敏感，编号错位常导致替换失败（比如想用 $2 却拿到域名而非协议）