一个看起来逻辑正常的正则遇到恶意或异常长的输入可能从几毫秒变成几十秒直接把服务的 CPU 顶到 100%。这篇文章用本机跑出来的数据说明回溯爆炸是怎么发生的并给出 3 个能直接落地的修复方法。为什么说这是“隐蔽雷”正则引擎大多采用回溯backtracking来处理可选分支。Pattern 里出现一个“量词包量词”时引擎会在不同拆法之间反复试路径数随输入长度指数增长。最经典的坏味道是这个importre patternre.compile(r^(a)$)它想表达“整串都是 a”。但如果输入是aaaaaaaa...X结尾多一个不匹配的X(a)和外面这个就会把前面几十个a拆成无数种组合每一种都要推到结尾才发现失败。字符串长度每加 1尝试次数就接近翻一倍。复现同一段匹配耗时怎么涨我把下面这段在 Python 3.14 本机跑了一遍改变n观察耗时importre,timedefmatch_time(n:int):sa*nXttime.perf_counter()re.match(r^(a)$,s)returntime.perf_counter()-tfornin(20,22,24,26):print(n,round(match_time(n),4))a 的个数本机耗时秒200.0392220.1565240.6256262.5148每多 2 个字符耗时约变为 4 倍套成单字符就是约 2 倍。按这个趋势n30会到几十秒n36就会上千秒。像(a)$这类模式只要输入长度不受控就是线上定时炸弹。OWASP 等安全资料里把这类问题统称为 ReDoS。3 步改写救回服务第一步去掉嵌套量词回到单一匹配路径。同样的“整串都是 a”直接写成线性模式importre# 原来会指数回溯re.fullmatch(r(a),s)# 改后一次扫到尾re.fullmatch(ra,s)大多数 ReDoS 都能靠这步解决把(a)、([a-z])、(\d)这种“一个字符组加一层量词外面再套一层量词”改成一层。第二步能改写就改写改不了就限制输入长度。有些复杂 pattern 不能简化那就先卡住输入if len(text) 512: reject。安全资料里的建议也类似——不可信的输入在做复杂解析前先限长。宁可拒绝“过长”也别让一个请求把整台机器拖住。第三步给匹配加超时防住漏网之鱼。Python 标准库的re没有内置超时这也是 ReDoS 在 Python 服务里容易失控的原因。第三方regex包提供了timeout参数importregextry:regex.match(r^(a)$,bad_text,timeout1)exceptTimeoutError:# 1 秒没匹配完就当失败处理不再死等pass如果不想引入新依赖就把正则放进工作进程执行主进程设个超时把它干掉。核心思路都一样匹配可以被拒绝但服务不能被一个表达式按死。结果与下一步这一轮跑完得到三个能直接带走的结论^(a)$这类“量词包量词”是本机实测的指数坑n从 20 到 26耗时从 0.04 秒涨到 2.5 秒。优先去嵌套量词改写其次限制输入长度最后用 timeout 兜底。看到网上复制来的复杂正则先扫一眼有没有两层量词套同一个字符组。Podcast 里常听到“一个正则让服务挂了”真正落地处理时别只补小时段重启先查 pattern 本身是不是 ReDoS。把这三步写进 code review 检查项比自己记几个零散案例更省心。
