量词嵌套极易引发指数级回溯，导致NFA引擎性能急剧下降；如(a+)+应简化为a+，.*.*?.*应替换为[^

量词嵌套是正则表达式中最容易引发严重性能退化的结构之一，尤其在 NFA 引擎（如 Python、Java、JavaScript、.NET）中，它会触发指数级回溯，导致匹配时间从毫秒飙升至数秒甚至超时。

为什么嵌套量词这么危险

当一个量词作用在另一个已有量词的子表达式上时（例如 (a+)+、(.*?)+、((\d{1,3}\.){3}\d{1,3})+），引擎必须尝试所有可能的切分方式来满足外层量词。字符串越长、可选路径越多，回溯组合呈爆炸式增长。比如匹配 "aaaaaaaa" 时，(a+)+ 可能以 a|a|a|...、aa|a|...、aaa|... 等数百种方式拆分，每种都需验证——这就是“灾难性回溯”。

典型高危模式与替代写法

以下常见写法应立即替换：

• (a+)+ → 改用 a+（语义不变，消除嵌套）
• .*<div>.*?</div>.* → 改为 [^[^[^（用否定字符类替代 <code>.，限制匹配范围）
• (\w+\s*)+ → 改为 \w+(?:\s+\w+)*（将嵌套转为线性重复，避免外层量词包裹可变长度子组）
• ^(.*+)*$ → 直接删除或重写逻辑（该模式无实际用途，纯属回溯陷阱）

Go 用户特别注意

Go 的 regexp 基于 RE2，虽不支持回溯，但面对 .* 类模糊通配仍会做完整线性扫描。若嵌套出现在类似 ([^"]*")* 这样的结构中，引擎需反复定位引号边界，在长文本中 CPU 耗时显著上升。建议：

• 用 "[^"]*" 明确匹配单个双引号字符串，而非试图一次捕获多个
• 对多段内容，先按分隔符（如换行、逗号）切片，再逐段匹配
• 必要时启用 regexp.FindAllStringSubmatch 配合预过滤，避免全量扫描

快速自查方法

遇到慢正则，先检查是否含以下特征：

• 两个及以上连续的 +、*、{n,m}，且至少一个在括号内、另一个在括号外
• 存在 . 或宽泛字符类（如 [\s\S]）配合嵌套或非锚定边界
• 未加 ^ 或 $ 锚点，导致引擎在每个位置都尝试嵌套匹配
• 使用了反向引用或捕获组嵌套量词（如 (\w+)\s+\1+）