正则测试

⭐ 觉得好用?收藏备用,下次直接打开
/ /
等待输入
测试文本
匹配结果
输入正则和文本后实时显示匹配
参考手册 点击语法可插入输入框

正则测试工具 实时展示匹配结果、分组捕获、替换预览,支持主流方言(JavaScript / PCRE / Python / Java)和 flag 切换。

核心语法速查

  • 字符类\d 数字、\w 单词字符(字母数字下划线)、\s 空白、. 任意字符(不含换行)、[abc] 枚举、[^abc] 排除
  • 量词? 0-1 次、* 0+ 次、+ 1+ 次、{n,m} n-m 次、后加 ? 变懒惰(如 .*?
  • 锚点^ 行首、$ 行末、\b 单词边界
  • 分组(...) 捕获组、(?:...) 非捕获、(?P<name>...) 命名捕获(Python/PCRE)

常用 flag

  • i 忽略大小写
  • g 全局(找所有匹配,默认只找第一个)
  • m 多行(让 ^$ 对每行生效)
  • s dotall(让 . 匹配换行)
  • u Unicode 模式

实战要点

  • 验证型正则加 ^...$ 锚定首尾,避免”匹配子串就算数”
  • 批量替换用 $1$2 引用捕获组
  • 性能敏感场景避开嵌套量词((a+)+)防回溯爆炸
  • PCRE 方言最强,Go 的 RE2 最稳(线性时间)

📍使用场景

  • 验证输入格式邮箱、手机号、身份证号等常见字段的校验规则一次性调通。
  • 批量文本替换代码重构或日志清洗时,用捕获组一次替换上千处而不误伤。
  • 日志/数据提取从乱码日志里抓出时间戳、IP、URL、错误码等结构化字段。

常见问题

为什么 `.*?` 比 `.*` 在某些场景更安全?

`.*` 是贪婪匹配,会尽可能多吃字符;`.*?` 是懒惰(非贪婪)匹配,尽可能少吃。例如 `<.*>` 匹配 `<b>bold</b>` 会吃掉整个字符串(到最后一个 `>`),`<.*?>` 只匹配到第一个 `>`。提取 HTML 标签、JSON 字段时优先用懒惰匹配,避免"吞"过界。

`(...)` 和 `(?:...)` 有什么区别?

`(...)` 是捕获组,可通过 `$1`、`\1` 或 `match.group(1)` 引用;`(?:...)` 是非捕获组,只分组不捕获,性能略好,编号不占位。替换场景用捕获组;仅需分组逻辑(比如 `(?:foo|bar)+`)用非捕获组避免污染捕获编号。

`\d` 和 `[0-9]` 一样吗?

大多数语言下在 ASCII 范围内等价。但启用 Unicode 模式(JS `u` flag、Python `re.UNICODE`)后 `\d` 匹配所有 Unicode 数字(阿拉伯数字、全角数字、藏数字等),范围更广;`[0-9]` 始终只匹配 ASCII 0-9。表单校验场景建议用 `[0-9]` 更保守。

不同语言写正则有什么差异?

三大差异——转义:JavaScript 用字面量 `/\d+/` 免二次转义;Java 字符串里要 `"\\d+"`;Python 推荐 `r"\d+"` 原始字符串。flag 写法:JS 写在末尾 `/…/gi`;Python 传参 `re.IGNORECASE`;Java 传 `Pattern.CASE_INSENSITIVE`。方言:PCRE(PHP/Perl)最强;Go 的 RE2 禁用反向引用和回溯(保证线性时间);JS 支持度居中。

正则会导致性能问题吗?

会。灾难性回溯(Catastrophic Backtracking)是主要元凶,模式形如 `(a+)+` 配合不匹配输入可能指数级爆炸,几秒到几分钟不收敛,2019 年 Cloudflare 就因此宕机。避免方法:减少嵌套量词、用原子组 `(?>...)` 或占有量词 `a++`、优先用 Go 的 RE2 引擎。复杂替换建议测试极端输入。

常用正则有哪些?

邮箱 `^[\w.+-]+@[\w-]+(\.[\w-]+)+$`;中国手机号 `^1[3-9]\d{9}$`;18 位身份证 `^\d{17}[\dX]$`;IPv4 `^(\d{1,3}\.){3}\d{1,3}$`(需再做 0-255 范围校验);URL `^https?://[^\s]+$`;中文 `[\u4e00-\u9fa5]`。参考教程 `common-regex-10-patterns` 有更细分场景。