正则性能差异核心在于回溯量：贪婪模式易致指数级回溯（如/a+b+c/在失败时），非贪婪虽回溯逻辑不同，但成功匹配时贪婪更快；优化关键为避免嵌套量词、使用原子组或明确边界。
正则表达式中贪婪与非贪婪模式的性能差异，核心不在于“谁更快”，而在于“匹配行为不同导致回溯量剧变”，进而显著影响执行时间——尤其在长文本、复杂模式或失败匹配场景下。
贪婪模式容易引发大量回溯
贪婪量词（如 *、+、{n,}）会先尽可能多地匹配字符，再逐步“吐出”字符尝试满足后续模式。若后续匹配失败，引擎需反复回溯，时间复杂度可能升至指数级。
例如：/a+b+c/ 在字符串 "aaaaaaaaab" 上匹配失败时，引擎会尝试：
- 用全部 9 个
a匹配a+，再找b→ 找到第 10 位的b，接着找c→ 失败； - 回退，用 8 个
a匹配，再找b→ 同样卡在c； - 持续回退直到 1 个
a，仍失败……共约 9 次尝试。
字符串越长，回溯路径越多。某些恶意构造的正则（如 /(a+)+b/）甚至可触发“灾难性回溯”，使页面卡死。
立即学习“Java免费学习笔记（深入）”；
非贪婪模式未必更慢，但回溯逻辑不同
非贪婪量词（如 *?、+?、{n,}?）优先取最少字符，再逐步“吃进”以满足后续。它通常比贪婪模式更早失败，回溯次数更少。
同例：/a+?b+c/ 在 "aaaaaaaaab" 中：
- 先用 1 个
a匹配a+?，再找b→ 找到第 10 位的b，接着找c→ 失败； - 于是增加
a数量：2 个 → 找b→ 还是第 10 位 → 再找c→ 失败； - 继续扩展，直到用满 9 个
a，仍失败，共约 9 次尝试——看似一样？
但关键区别在于：非贪婪模式在**成功匹配场景下往往更高效**。比如匹配 "aaabbbccc" 中的 "aaabbb"（即 /a+b+/ vs /a+?b+?/），贪婪模式一步到位，而非贪婪模式需多次扩展，此时贪婪反而更快。
真正影响性能的是“是否必须回溯”
性能瓶颈本质来自回溯，而非量词本身。以下写法可大幅降低风险：
-
避免嵌套量词：如
(a+)+、(\w+:\w+)+是回溯重灾区； -
用原子组或占有量词（ES2024+）：
/(?>a+)b+c/或/a++b+c/禁止回溯a+部分，失败即终止； -
用明确边界替代模糊量词：把
/".*"/改为/"[^"]*"/，彻底消除回溯可能； -
优先使用非贪婪仅当语义需要：比如提取第一个
img标签：/<img alt="JavaScript中正则贪婪模式与非贪婪模式的性能差异" >]*?>/i比/<img alt="JavaScript中正则贪婪模式与非贪婪模式的性能差异" >]*>/i更安全且高效。
实测建议：用 Chrome DevTools 的 Performance 面板 或 console.time() 对比
不要凭经验猜测。对关键正则做真实数据测试：
- 准备典型输入（含成功、失败、边界长度）；
- 分别测试
/a+b+c/和/a+?b+?c/； - 观察耗时差异——多数情况下，差异微乎其微；但一旦出现灾难性回溯，贪婪版可能耗时数秒，非贪婪版仅毫秒级。
不复杂但容易忽略：性能优化的第一步，是确认你的正则是否存在回溯隐患，而不是盲目切换贪婪或非贪婪。
