正则表达式性能瓶颈在于回溯失控而非贪婪或非贪婪本身；贪婪模式在嵌套量词或模糊通配下易引发指数级回溯，非贪婪虽尝试更少但未必更快；真正优化应避免嵌套、用字符类替代.、设明确终止符并实测验证。
正则表达式中贪婪与非贪婪匹配的性能代价，核心不在“谁更慢”，而在于回溯行为是否失控——它可能让毫秒级操作变成数秒卡顿，甚至引发页面冻结。
回溯是性能杀手，不是量词本身的问题
正则引擎靠回溯来试探匹配路径。贪婪模式先吃尽所有可能字符，再一步步“吐出来”尝试后续条件；非贪婪模式则从小开始“一点点吃”，直到满足整体模式。
两者在简单成功匹配时耗时接近，但一旦失败或文本复杂，差异就爆发了：
- 贪婪模式在嵌套量词（如
(a+)+b）或模糊通配（如.*）下，回溯次数可能呈指数增长 - 非贪婪模式虽也回溯，但通常更早触达失败边界，总尝试次数更少
比如匹配失败字符串 "aaaaaaaaab" 时：
-
/a+b+c/（贪婪）会尝试 9 次回溯（用 9 个 a → 8 个 a → … → 1 个 a） -
/a+?b+c/（非贪婪）同样约 9 次，但逻辑上更早放弃长跨度，实际执行更稳定
真正危险的是像 /(a+)+b/ 这类写法——长度每增 1，回溯量翻倍，10 个 a 就超百万次尝试。
非贪婪不等于自动优化
很多人以为加个 ? 就安全，但若上下文没约束，非贪婪反而更慢：
- 匹配
"aaabbbccc"中a+b+时，贪婪一步到位；非贪婪要反复扩展a+?和b+?，多做无效试探 - 在日志解析中用
error:.*（贪婪）可能回溯数万次，但换成error:[^: ]*（明确排除符）比error:.*?更快、更确定
关键不是贪不贪，而是能否避免回溯。
真正有效的降本策略
比起纠结 * 还是 *?，优先做这几件事：
- 用字符类替代
.："([^"]*)"比".*?"快且无回溯风险 - 避免嵌套量词：把
(w+:w+)+拆成单层循环处理，或改用(?>(?:w+:w+)+)（原子组） - 设置明确终止符：提取 URL 时用
https?://[^\s>"]+，而非https?://.*?(?=s| - 浏览器中用
console.time()实测：对真实数据（含边界、失败、超长输入）跑对比，别猜
性能瓶颈从来不是语法糖，而是模式设计是否尊重文本结构。
