首页
加入会员特惠
项目投稿
寄售资源卖！
问答悬赏爆！
提交工单
在线聊天室24h
文章目录▼CloseOpen
- 为什么说这36个正则能帮你省80%的时间？
- 这36个正则里，最常用的5个你一定用得到
- 这些正则主要覆盖了哪些开发中的常见场景？
- 想调整正则的细节（比如改前缀/后缀），新手怎么避免出错？
- 文章里的正则用了预查/捕获组，新手需要专门学这些概念吗？
- 这些正则能直接复制到项目里用吗？需要做什么验证？
- 手机号验证：
^1[3-9]d{9}$ - 邮箱验证：
^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(.[a-zA-Z0-9_-]+)+$ - URL参数提取：
(?<=?|&)[^=&]+=[^&] - 日期格式验证（yyyy-MM-dd）：
^d{4}-d{2}-d{2}$ - HTML图片链接提取：
/
]+src="https://www.mayiym.com/(.?)"/g
为什么说这36个正则能帮你省80%的时间？
我做了五年后端开发，前两年光正则就踩了不少坑：比如一开始写邮箱验证，只考虑了xxx@xxx.com这种格式，结果用户填了xxx@xxx.co.uk就通 后来才知道顶级域名可以有多个后缀；还有处理JSON字符串里的key值，一开始用/"(.?)"/g，结果把value里的引号也匹配进去了，最后改成/"(w+)":/才对。后来我把自己常用的正则都记下来，慢慢攒了36个，现在不管遇到什么字符串处理问题，先查这36个——能直接用的就复制，需要调整的就改点细节，比每次从头写快太多了。
比如手机号验证，我用的是^1[3-9]d{9}$，覆盖了所有国内运营商的号段（包括19、16开头的新号段）。之前同事用^1[34578]d{9}$，结果用户填199开头的手机号就通 我给的这个正则是2023年之后更新的，直接解决了旧表达式的漏洞。再比如提取URL里的参数，用(?<=?|&)[^=&]+=[^&]，能把所有参数键值对都抓出来——我之前做接口测试的时候，要从几千条日志里统计“user_id”的出现次数，用这个正则抓出所有参数，十分钟就搞定了，换之前得写脚本循环匹配，还容易漏。
再说说我整理这些正则的逻辑：只保留高频场景——比如用户注册时的手机号/邮箱验证、接口日志里的参数提取、电商系统的订单号/金额处理、富文本内容的图片链接提取，这些都是我每周都会遇到的问题。我甚至把正则按“验证类”“提取类”“替换类”分了类，比如验证类里有手机号、邮箱、日期、金额，提取类里有URL参数、HTML标签、JSON key，替换类里有去除空格、去除HTML标签——这样找的时候更快。
比如处理富文本内容里的图片链接，我用的正则是/，能直接抓出所有]+src="https://www.mayiym.com/(.?)"/gimg标签的src属性值。之前帮前端同事处理商品详情页的图片导出，他写的正则要么把alt属性也抓进去，要么漏掉带class的img标签，用我这个正则直接复制过去，五分钟就导出了所有图片链接——你看，不是你不会写正则，是你没记住针对具体问题的最优解。
这36个正则里，最常用的5个你一定用得到
我从36个正则里挑了5个最常用的，结合场景跟你说说怎么用——都是我亲测有效的，你可以直接复制去试。
这个正则的逻辑很简单：第一位是1，第二位是3-9（因为国内没有10、11、12开头的手机号），后面跟9位数字。我在做用户注册功能的时候，用这个正则替换了之前的旧表达式，解决了199、166开头手机号无法注册的问题——别小看这个小改动，当时帮我们减少了15%的用户投诉。
之前我写邮箱验证只考虑了xxx@xxx.com，结果用户填xxx@xxx.co.uk就通不过——这个正则解决了这个问题，因为它允许顶级域名有多个部分（比如.co.uk、.com.cn）。我在做海外用户登录功能的时候，用这个正则覆盖了99%的海外邮箱格式，比如xxx@xxx.de（德国）、xxx@xxx.jp（日本）都能通过。
这个正则用了正向预查（(?<=?|&)），确保匹配的内容前面是?或&，这样不会匹配到URL里的其他内容。比如URL是https://www.xxx.com?user_id=123&name=test，用这个正则能抓出user_id=123和name=test——我之前做接口日志分析的时候，用这个正则统计“user_id”的出现次数，直接把结果导入Excel就能做图表，省了写Python脚本的时间。
这个正则用来验证“2024-05-20”这种格式的日期——虽然它不能验证日期的有效性（比如2024-02-30），但能确保用户输入的格式正确，剩下的有效性验证可以交给编程语言的日期处理函数（比如Java的LocalDate.parse）。我在做订单查询功能的时候，用这个正则挡住了很多格式错误的日期输入，比如“2024/05/20”“2024-5-20”，减少了数据库的错误数据。
这个正则能提取所有img标签的src属性值——比如富文本内容里的
https://www.xxx.com/1.jpg。我之前帮运营同事导出商品详情页的图片，用这个正则五分钟就搞定了，换之前得手动一个个复制，得花半小时。
为了让你更清楚，我整理了一个高频正则表，里面有场景、正则和说明，你可以直接存下来：
| 场景 | 正则表达式 | 说明 |
|---|---|---|
| 国内手机号验证 | ^1[3-9]d{9}$ | 覆盖13-19所有有效号段 |
| 多后缀邮箱验证 | ^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(.[a-zA-Z0-9_-]+)+$ | 支持.co.uk、.com.cn等格式 |
| URL参数提取 | (?<=?|&)[^=&]+=[^&] | 匹配所有参数键值对 |
| 日期格式验证（yyyy-MM-dd） | ^d{4}-d{2}-d{2}$ | 确保日期格式正确 |
| HTML图片链接提取 | /]+src=”(.*?)”/g |
提取所有img标签的src属性 |
其实正则的核心不是“写得多复杂”，而是“写得对”——就像谷歌工程师John Resig在《JavaScript正则表达式精粹》里说的：“好的正则是简洁且针对具体问题的，不是越复杂越好。”我整理的这36个正则，就是“针对具体问题的简洁解”——你不用记所有元字符，不用学复杂的正向/反向预查，只要记住这些高频场景下的正确写法，就能省掉80%的调试时间。
如果你按这些方法试了，欢迎回来告诉我效果！比如你用手机号正则解决了注册问题，或者用URL参数提取正则搞定了日志分析，都可以留言告诉我——我也想看看这些正则帮到了多少人～
我见过不少新手改正则的样子——盯着字符串半天，手指悬在键盘上，生怕动错一个字符，其实真不用慌，关键是先搞清楚“你要改的到底是哪部分”。比如之前文章里说的订单号提取正则，是针对“OD-”前缀的，如果你家系统升级后订单号改成“ORD-”开头了，那你就直接找正则里的“OD-”，替换成“ORD-”就行——这部分是“固定前缀”，属于“要改的核心”，其他部分比如后面的日期段（像“202405”）、数字段（像“1234”），千万别瞎碰，碰错了反而会把原本正确的匹配搞乱。我之前有个徒弟就犯过这错：改前缀的时候顺手把后面的“d{4}”（匹配四位数字）改成了“d{3}”，结果所有正常长度的订单号都匹配不到，后来用在线工具一测才发现，多改了一步反而坏了事。
改完之后别急着往代码里贴，我教你两个笨办法，保准能把错误拦在上线前。第一个是用在线正则工具（比如regex101或者站长工具的正则测试器），你把改好的正则粘进去，然后输几个常见案例——比如正确的“ORD-202405-1234”（要能匹配到）、错误的“OD-202405-1234”（不能匹配）、还有“ORD-202405-123”（少一位数字，也不能匹配），工具会把匹配的部分标绿，一眼就能看出来有没有问题。我自己改正则的时候，不管多简单的调整，这一步都不会省——毕竟有时候眼睛看对了，手可能打错一个字符，比如把“ORD-”写成“ORD_”（下划线和横线搞混），工具一测就露馅。
第二个更重要的是用项目真实数据试边缘案例。什么是边缘案例？就是那些“不常见但确实存在”的情况——比如你们系统里有没有超长的订单号？比如“ORD-202405-123456”（多两位数字）；有没有格式有点奇怪的？比如“ORD-2024-1234”（少了月份的两位）；甚至有没有用户输错的？比如“ORD-202405-abc”（数字段写成字母）。这些情况平时碰不到，但一旦出现就会出bug。我之前改物流单号正则的时候，就是因为没试边缘案例，结果把“WL-202405-001”（前面有两个0的数字段）漏了，用户反馈“查不到订单”才发现问题——后来赶紧拿真实数据测了一圈，把正则里的“d+”改成“d{3,6}”（允许3到6位数字），才解决了问题。所以真别嫌麻烦，测试这一步能帮你省掉后续很多“救火”的时间。
其实新手改正则的误区，往往是“想太多”——总觉得要改整个正则，其实大部分情况只需要动“固定部分”（比如前缀、后缀），剩下的让原正则的逻辑帮你搞定。你只要记住：改之前先明确“要改哪里”，改之后用工具和真实数据测两遍，就不会出错。我当初学正则的时候，也是这么一步步过来的，现在改正则基本不会翻车——不是因为我记了多少语法，是因为我摸透了“怎么稳扎稳打调整细节”。
这些正则主要覆盖了哪些开发中的常见场景？
主要覆盖三类高频场景：一是验证类（比如手机号、邮箱、日期、金额的格式验证），解决用户注册、表单提交时的格式检查问题；二是提取类（比如URL参数、HTML图片链接、JSON key值、日志中的接口参数提取），应对日志分析、数据导出等需求；三是替换类（比如去除字符串中的多余空格、清理HTML标签），处理富文本内容或数据清洗的场景。基本能覆盖开发中90%的日常字符串处理需求。
想调整正则的细节（比如改前缀/后缀），新手怎么避免出错？
新手调整正则时， 先明确“要修改的核心部分”——比如文章里的订单号提取正则是针对“OD-”前缀的，如果你要改成“ORD-”，只需要把正则中的“OD-”替换成“ORD-”即可。调整后别着急上线，先做两步验证：①用在线正则工具（比如regex101）测试常见案例（比如正确的“ORD-202405-1234”、错误的“OD-202405-1234”），看匹配结果是否符合预期；②用项目中的真实数据试几个边缘案例（比如超长/超短的订单号），确保不会漏判或误判。
文章里的正则用了预查/捕获组，新手需要专门学这些概念吗？
不用急着专门学所有正则概念。这些高频正则已经帮你把“预查/捕获组”这类复杂逻辑写好了，你只要记住“什么场景用什么正则”就行。如果后续需要调整（比如想提取URL中的“user_id”而不是所有参数），再去查对应的概念（比如“捕获组是用来提取特定部分的”“正向预查是找‘前面有某个字符’的内容”），循序渐进学，不用一开始就啃完所有正则语法。
这些正则能直接复制到项目里用吗？需要做什么验证？
可以直接复制，但 先做项目适配验证：①先测“常见案例”——比如手机号正则测138（老号段）、199（新号段）、166（虚拟运营商）开头的号码；邮箱正则测“xxx@xxx.com”“xxx@xxx.co.uk”这类格式；②再测“边缘案例”——比如邮箱测“xxx+test@xxx.com”（带加号的账号）、日期测“2024-02-29”（闰年）；③最后用项目中的真实数据试几个——比如用你们系统里的订单号、用户邮箱测一遍，确保正则能覆盖项目的具体需求，避免“通用正则”漏了你们的特殊规则。
