正则表达式中的哪些隐藏陷阱值得特别注意？

2026-03-30 09:511阅读0评论SEO问题

内容介绍
文章标签
相关推荐

本文共计1990个文字，预计阅读时间需要8分钟。

最近几天监控到一个项目，突然报告异常。检查机器相关资源使用情况，发现CPU利用率接近100%。使用Java自带的线程转储工具，导出了问题堆栈信息。

前几天线上一个项目监控信息突然报告异常，上到机器上后查看相关资源的使用情况，发现 CPU 利用率将近 100%。通过 Java 自带的线程 Dump 工具，我们导出了出问题的堆栈信息。

我们可以看到所有的堆栈都指向了一个名为 validateUrl 的方法，这样的报错信息在堆栈中一共超过 100 处。通过排查代码，我们知道这个方法的主要功能是校验 URL 是否合法。

很奇怪，一个正则表达式怎么会导致 CPU 利用率居高不下。为了弄清楚复现问题，我们将其中的关键代码摘抄出来，做了个简单的单元测试。

public static void main(String[] args) { String badRegex = "^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~\\\\/])+$"; String bugUrl = "www.fapiao.com/dddp-web/pdf/download?request=6e7JGxxxxx4ILd-kExxxxxxxqJ4-CHLmqVnenXC692m74H38sdfdsazxcUmfcOH2fAfY1Vw__%5EDadIfJgiEf"; if (bugUrl.matches(badRegex)) { System.out.println("match!!"); } else { System.out.println("no match!!"); } }

当我们运行上面这个例子的时候，通过资源监视器可以看到有一个名为 java 的进程 CPU 利用率直接飙升到了 91.4% 。

看到这里，我们基本可以推断，这个正则表达式就是导致 CPU 利用率居高不下的凶手！

于是，我们将排错的重点放在了那个正则表达式上：

^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~\\/])+$

这个正则表达式看起来没什么问题，可以分为三个部分：

第一部分匹配 |[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~\\/])+$

出现问题的 URL 是：

www.fapiao.com/dzfp-web/pdf/download?request=6e7JGm38jfjghVrv4ILd-kEn64HcUX4qL4a4qJ4-CHLmqVnenXC692m74H5oxkjgdsYazxcUmfcOH2fAfY1Vw__%5EDadIfJgiEf

我们把这个正则表达式分为三个部分：

第一部分：校验协议。^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)。
第二部分：校验域名。(([A-Za-z0-9-~]+).)+。
第三部分：校验参数。([A-Za-z0-9-~\\/])+$。

我们可以发现正则表达式校验协议这部分是没有问题的，但是在校验 www.fapiao.com 的时候，其使用了 xxxx. 这种方式去校验。那么其实匹配过程是这样的：

匹配到 www.匹配到 fapiao.
匹配到 com/dzfp-web/pdf/download?request=6e7JGm38jf.....，你会发现因为贪婪匹配的原因，所以程序会一直读后面的字符串进行匹配，最后发现没有点号，于是就一个个字符回溯回去了。

这是这个正则表达式存在的第一个问题。

另外一个问题是在正则表达式的第三部分，我们发现出现问题的 URL 是有下划线（_）和百分号（%）的，但是对应第三部分的正则表达式里面却没有。这样就会导致前面匹配了一长串的字符之后，发现不匹配，最后回溯回去。

这是这个正则表达式存在的第二个问题。

解决方案

明白了回溯是导致问题的原因之后，其实就是减少这种回溯，你会发现如果我在第三部分加上下划线和百分号之后，程序就正常了。

public static void main(String[] args) { String badRegex = "^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~_%\\\\/])+$"; String bugUrl = "www.fapiao.com/dddp-web/pdf/download?request=6e7JGxxxxx4ILd-kExxxxxxxqJ4-CHLmqVnenXC692m74H38sdfdsazxcUmfcOH2fAfY1Vw__%5EDadIfJgiEf"; if (bugUrl.matches(badRegex)) { System.out.println("match!!"); } else { System.out.println("no match!!"); } }

运行上面的程序，立刻就会打印出match!!。

但这是不够的，如果以后还有其他 URL 包含了乱七八糟的字符呢，我们难不成还再修改一遍。肯定不现实嘛！

其实在正则表达式中有这么三种模式：贪婪模式、懒惰模式、独占模式。

在关于数量的匹配中，有 + ? * {min,max} 四种两次，如果只是单独使用，那么它们就是贪婪模式。

如果在他们之后加多一个 ? 符号，那么原先的贪婪模式就会变成懒惰模式，即尽可能少地匹配。但是懒惰模式还是会发生回溯现象的。例如下面这个例子：

text="abbc" regex="ab{1,3}?c"

正则表达式的第一个操作符 a 与字符串第一个字符 a 匹配，匹配成功。于是正则表达式的第二个操作符 b{1,3}? 和字符串第二个字符 b 匹配，匹配成功。因为最小匹配原则，所以拿正则表达式第三个操作符 c 与字符串第三个字符 b 匹配，发现不匹配。于是回溯回去，拿正则表达式第二个操作符 b{1,3}? 和字符串第三个字符 b 匹配，匹配成功。于是再拿正则表达式第三个操作符 c 与字符串第四个字符 c 匹配，匹配成功。于是结束。

如果在他们之后加多一个 + 符号，那么原先的贪婪模式就会变成独占模式，即尽可能多地匹配，但是不回溯。

于是乎，如果要彻底解决问题，就要在保证功能的同时确保不发生回溯。我将上面校验 URL 的正则表达式的第二部分后面加多了个 + 号，即变成这样：

^([hH][tT]{2}[pP]:\/\/|[hH][tT]{2}[pP][sS]:\/\/) (([A-Za-z0-9-~]+).)++ --->>> （这里加了个+号） ([A-Za-z0-9-~_%\\\/])+$

这样之后，运行原有的程序就没有问题了。

最后推荐一个网站，这个网站可以检查你写的正则表达式和对应的字符串匹配时会不会有问题。

Online regex tester and debugger: PHP, PCRE, Python, Golang and JavaScript

例如我本文中存在问题的那个 URL 使用该网站检查后会提示：catastrophic backgracking（灾难性回溯）。

当你点击左下角的「regex debugger」时，它会告诉你一共经过多少步检查完毕，并且会将所有步骤都列出来，并标明发生回溯的位置。

本文中的这个正则表达式在进行了 11 万步尝试之后，自动停止了。这说明这个正则表达式确实存在问题，需要改进。

但是当我用我们修改过的正则表达式进行测试，即下面这个正则表达式。

^([hH][tT]{2}[pP]:\/\/|[hH][tT]{2}[pP][sS]:\/\/)(([A-Za-z0-9-~]+).)++([A-Za-z0-9-~\\\/])+$

工具提示只用了 58 步就完成了检查。

总结

以上所述是小编给大家介绍的藏在正则表达式里的陷阱，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对易盾网络网站的支持！

标签：陷阱推荐前几