正则圈有个梗：「写一个验证邮箱的正则，出来的是测试工程师噩梦」。网上随手搜的 email 正则要么短到漏一半，要么长到像勒索软件。这篇不玩虚的，直接给你 7 个生产环境验证过的模式——不追求学术严格，追求实战可用。配合 Piick 正则测试工具 一边看一边调。

为什么”万能正则”不存在

RFC 5322 标准的邮箱格式定义有几百行，合法邮箱可以长得像 "user+tag"@sub.example.museum 这种。试图用一条正则覆盖所有合法情况，结果就是写出一坨 200 字符的「正则怪物」，半年后你自己都不敢动。

实战原则：用「99% 命中」的简化版，剩下 1% 让后端发验证邮件兜底。验证邮箱不要靠前端正则，要靠服务端实际发件。

7 个高频场景的最佳正则

下面 7 条都来自生产代码，覆盖最常见需求：

  1. 邮箱 [A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,} ——简化版，99% 邮箱通过
  2. URL https?:\/\/[^\s<>"']+ ——http/https 开头到空格或尖引号
  3. 手机号（国际） \+?[1-9]\d{1,14} ——E.164 格式，最长 15 位
  4. IPv4 地址 \b(?:25[0-5]|2[0-4]\d|[01]?\d?\d)(?:\.(?:25[0-5]|2[0-4]\d|[01]?\d?\d)){3}\b ——严格 0-255 分段
  5. ISO 日期 \d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01]) ——年-月-日，月份和日期做了范围校验
  6. 十六进制颜色 #?([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})\b ——#fff #FFFFFF 都吃
  7. URL slug [a-z0-9]+(?:-[a-z0-9]+)* ——字母数字加中划线，文章 URL 通用

Piick 正则测试工具 的「Common Patterns」下拉已经内置了这 7 条——粘进去直接用，不用自己手敲。

用 Piick 实时测试 + 微调

复制别人写的正则有个坑：自己都不知道哪段什么意思。Piick 的「Explain」面板按 token 拆解正则，告诉你每个括号、每个量词的作用：

  • 元字符（\d、\w、\b）用 anchor / class 标注
  • 量词（*、+、{2,5}）用 quantifier 标注
  • 分组和反向引用用 group / backref 标注

调试流程：粘正则 → 看 Explain 拆解 → 粘测试文本 → 看 matches 高亮 → 改一行 → 立刻看效果。整个过程不刷新页面，改完即跑。

自定义模式库的小技巧

3 个让正则更好维护的习惯：

  1. 命名捕获组代替数字组：(?<year>\d{4}) 比 (\d{4}) 好读，后期提取数据时不会数错括号
  2. 复杂正则拆成多行 + 注释：new RegExp(\…`)` 配合注释变量，半年后你还能看懂
  3. 写在 lib/regex.ts 里集中维护——别到处 new RegExp(...)，改一次要找 50 个文件

更进一步：把项目里常用的正则存成一个对象，key 是名字，value 是 {pattern, flags, sample}。每个新人都能直接用，不用从头抄。这其实就是 Piick 正则测试工具 内置 7 个常见模式的思路——模式库越大，重复造轮子越少。

现在就打开 Piick 正则测试工具，点「Common Patterns」下拉选 email，粘一段测试文本进去看匹配效果。