正则表达式从入门到精通：50+ 实战模式速查
正则是开发者绕不过的工具，但语法晦涩。本指南从基础元字符到工业级模式（邮箱/手机/IP/密码强度），50+ 实战正则一次讲清。
正则表达式（Regular Expression / regex）是几乎所有编程语言、文本编辑器、日志工具都支持的字符串匹配语法。掌握它能让你 5 分钟做完 50 行 if 才能完成的事——但它的语法是出了名的反直觉，符号多、易错。本指南从最基础的元字符讲起，带你看懂业界最常用的 50+ 模式（邮箱、手机号、身份证、密码强度、URL、IP、日期、HTML 标签等），并给出每种模式的"陷阱版"对比。
正则的核心概念：贪婪与非贪婪
正则默认是"贪婪匹配"——尽量匹配最长的字符串。例如 <.*> 用于 <a><b> 时会匹配整个 <a><b>，而不是 <a>。
非贪婪用 ? 修饰：<.*?> 匹配最短可能，结果是 <a> 和 <b> 各一次。
实战经验：写正则时先想能不能用贪婪，错了再改非贪婪。99% 的初学者第一版正则都是匹配过长。
工业级正则的常见陷阱
"邮箱正则"看似简单，但写得漂亮和写得对是两件事：
- 入门版：
[a-z]+@[a-z]+\.[a-z]+——错过+._等合法字符 - 进阶版：
[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}——本工具采用，覆盖 99% 真实邮箱 - 完美版：RFC 5321 标准的邮箱正则有 6000+ 字符，不实用
实用建议：对邮箱、URL、电话这些"开放定义"格式，不要追求 100% 严格。本工具的中等版本能拦下绝大多数错输入，让真实合法地址通过——这才是验证的目的。
中文场景的关键模式
中文相关正则容易踩 Unicode 坑：
- 匹配中文字符：
[\u4e00-\u9fa5]是基本汉字范围，但不含部首扩展、生僻字、 emoji。要全覆盖用[\p{Script=Han}]（需uflag）。 - 手机号：
^1[3-9]\d{9}$是 2024 年通用，但虚拟号段（如 17X、19X）已经覆盖；早期 13X 起 4 位区间错过新号段会拦真实用户。 - 身份证：本工具的 18 位正则只校验格式合法性，不校验校验位。校验位需要用 ISO 7064 算法计算，是单独流程。
微信号、QQ 号、车牌号这些"中国特产"模式都在本工具的速查表里。
密码强度的三个层级
- L1 弱：6 位以上即可（淘宝早期、知乎旧版）。容易被字典攻击
- L2 中：8 位 + 字母 + 数字。本工具默认
- L3 强：8 位 + 大小写 + 数字 + 特殊符号。银行 / 政企标配
密码正则用了大量 (?=...) 正向预查，意思是"当前位置后面必须满足某模式但不消耗字符"。例如 (?=.*[A-Z]) 表示"字符串里某处必须有大写字母"。预查可叠加，是密码规则唯一不需要回溯的写法。
调试正则的两条铁律
- 永远先在测试器里跑过：本工具顶部的"在线测试"框就是为这个准备的。粘正则 + 粘文本，立即看是否匹配，错在哪一位。
- 不要在生产环境用未经测试的正则：尤其是用于安全验证的（密码、邮箱、URL）。一个写错的边界条件就能让攻击者绕过过滤。
复杂正则建议加注释（很多语言支持 (?x) flag 让正则跨行带注释），或者干脆拆成多个小正则用代码组合。可读性永远比"一行写完"重要。
常见问题
哪种语言的正则差异最大？
JavaScript 与 Python 几乎相同（PCRE 标准）；Perl 拥有最强大的正则支持；Java 与 .NET 也大致兼容；POSIX 正则（grep/awk）较弱，不支持非贪婪和零宽断言。
正则会拖慢性能吗？
会。某些灾难性回溯（catastrophic backtracking）的正则在恶意输入下能挂掉整个进程（见 ReDoS 漏洞）。生产环境用前用 safe-regex 库扫一下。
能用正则解析 HTML 吗？
理论上可以，实际上不建议。HTML 嵌套层级正则无法处理，应该用 DOM 解析器（cheerio / jsdom）。
中文 unicode 范围哪个最准确？
`\p{Script=Han}` 最准确，覆盖所有汉字脚本字符（含日韩共用汉字）。需启用 `u` flag。