作者：kaenfsk · 最后复核：2026 年 10 月 12 日 · 数据在浏览器本地处理 · 内容与维护标准
🧪 正则表达式测试工具
输入正则表达式、修饰符和测试文本，实时查看匹配结果与捕获组。数据只在本地处理。
正则表达式能做什么
正则表达式是用一组字符规则描述文本模式的方法。它可以帮助你判断文本是否符合格式、从长文本中提取指定片段、替换满足条件的部分，也可以用于表单校验、日志清洗和代码搜索。对于开发者来说，正则表达式是处理文本时最重要的基础能力之一。
一个完整表达式由普通字符和特殊字符组成。普通字符匹配自身，例如 abc 匹配文本中的 abc；特殊字符描述重复、位置或类别，例如 \d 匹配任意数字、+ 表示重复一次或多次。使用本工具时，你可以分别输入表达式和测试文本，立即看到表达式实际匹配了什么。
常用语法速查
- \d — 匹配一个数字；\w — 匹配字母、数字或下划线
- . — 匹配除换行外的任意字符
- * — 前面的字符出现 0 次或多次；+ — 出现 1 次或多次
- ? — 出现 0 次或 1 次；{2,5} — 出现 2 到 5 次
- [abc] — 匹配括号内任意一个字符；[^a] — 匹配不是 a 的字符
- (ab) — 捕获组；(?:ab) — 不捕获的分组
- ^ — 行首；$ — 行尾
测试步骤
- 在第一个输入框填写正则表达式，可以省略两端的斜杠
- 在修饰符中填写需要的标志，例如 g 表示全局匹配，i 表示忽略大小写，m 表示多行模式
- 把目标文本粘贴到测试文本区域
- 点击测试，工具会列出每个匹配的起始位置和内容
- 需要精确查找特殊字符时，先点击“转为字面量”再测试
捕获组怎么用
捕获组把匹配内容的一部分单独保存。例如表达式 (\d{4})-(\d{2})-(\d{2}) 可以匹配日期，并把年、月、日分别放进三个捕获组。本工具会在结果中显示捕获组内容，方便你确认分组是否正确。捕获组也常用于替换：在支持正则的编辑器或编程语言中，可以用 $1、$2 引用对应分组。
常见错误与排查
- 漏掉转义 — 匹配点号、括号、加号时应写成 \.、\(、\+
- 忘记全局标志 — 不加 g 时通常只返回第一个匹配
- 误用贪婪匹配 — .* 会尽可能匹配更长内容，需要最短匹配时使用 .*?
- 中文与转义 — 中文可以直接匹配，但推荐使用 Unicode 属性或明确字符范围，避免编码差异
- 测试数据不典型 — 至少准备正常、边界、错误三类样例，避免表达式只对单一输入有效
实战示例
验证邮箱时可以使用 [A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}；提取手机号可先明确长度与开头，例如 1[3-9]\d{9}。不同业务对格式要求不同，测试时应根据真实规则调整，而不是直接复制网上表达式。
安全与隐私
正则测试完全在浏览器本地执行，输入的正则表达式和测试文本不会上传到服务器。你可以在不担心数据泄露的前提下测试包含日志、SQL 或敏感字段的文本。
从需求到表达式：先想清楚要匹配什么
编写表达式之前，先明确几个问题：允许哪些字符？内容必须从什么位置开始或结束？是检查整段文本是否符合格式，还是从长文本中找出符合条件的片段？例如校验“8 到 20 位字母数字”时，^[A-Za-z0-9]{8,20}$ 会限制整行；而如果只希望提取文本里的数字，就不需要锚定首尾，直接用 \d+ 并开启全局匹配即可。
把需求写成几条“允许/不允许”规则，能显著减少返工。手机号、身份证、邮箱、订单号这类格式看似相似，实际边界差异很大：有的支持国际区号，有的允许空格，有的前后缀可以变化。先用测试文本把正常、边界和非法样例都列出来，再写表达式，比写完再猜要可靠得多。
什么时候要考虑表达式性能
在短文本上测试时，表达式是否高效通常看不出来。进入日志、源码或数据库导出的长文本后，嵌套量词可能让匹配变得很慢，甚至出现灾难性回溯。常见的危险写法包括 (a+)+、(.*)* 这类量词叠加：输入不匹配时，引擎会尝试大量组合。
本工具对结果数量做了上限保护，适合验证表达式逻辑。处理超长文本前，可以先在小样例上确认结果，再拆分数据或换用更具体的字符范围。例如需要提取多个数字时，尽量写 \d{1,3} 或 \d+，而不是用点号加量词描述整段结构。把复杂校验拆成多次简单匹配，往往比写一个难以维护的超长表达式更好。
多行文本与中文内容怎么处理
默认情况下，正则中的 ^ 和 $ 通常只表示整段文本的开始和结束；处理多行日志时，如果希望每一行都被当作独立单位，可以开启 m（multiline）修饰符。点号默认不匹配换行，需要跨行匹配时再按业务情况使用 s（singleline）模式，不要习惯性把所有修饰符都加上。
中文不需要特殊转义，直接在表达式里写汉字或字符类即可。需要处理全角与半角混用、Unicode 组合字符或 Emoji 时，要注意不同运行环境的支持差异。把中文文本按 UTF-8 处理后，再使用明确范围（例如常见汉字区段）会更容易得到一致结果。
编辑器、脚本与在线测试的区别
同一个表达式在不同环境中的语法可能略有差异：JavaScript 支持 d、u 等标志，Python 的原始字符串写法不同，命令行工具默认按行处理。在线测试工具最适合验证逻辑，正式接入代码后仍要用目标语言自己的测试框架跑一遍边界用例。
把表达式放入代码前，还应考虑转义层级。HTML 属性、JSON 字符串、Shell 引号都会影响最终传给正则引擎的文本。遇到“页面里看起来正确、程序里却报错”的情况，多半是转义或标志位不同，而不是正则语法本身的问题。
从日志需求到表达式：三个实操样例
先写出“要提取什么”，再选择是否需要锚点、捕获组和长度约束。下面的表达式是提取候选值的起点，不等于完成业务校验。订单号、邮箱或时间字段最终还应在程序中验证类型、范围、重复和权限。
| 日志目标 | 候选表达式 | 输入示例 | 边界 |
|---|---|---|---|
| 提取订单号 | \bORD-\d{8}\b | ORD-20261012 | 大小写和前缀长度需按系统固定 |
| 提取时间字段 | \b\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\b | 2026-10-12 15:30:00 | 只证明格式，日期合法性需二次校验 |
| 提取候选邮箱 | [A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,} | dev@example.com | 邮箱真正有效性需发送验证或按域名规则处理 |
测试数据至少覆盖哪些情况
只用一个成功样例无法证明表达式安全。至少准备正常值、过大值、空字符串、前后空格、大小写变化、中英文混排、换行、特殊符号和超长重复串。对于邮箱和 URL，不要追求一个正则覆盖所有理论情况；先匹配语法候选，再交给专门的解析器或业务校验函数。测试通过后，把输入样例和预期结果一起写入代码仓库，方便后续修改时回归。
发布前的检查清单
- 用至少一组正常输入确认能够匹配
- 用空值、超长值、全角字符等边界输入确认行为
- 明确是否包含首尾锚定，避免只匹配到错误片段
- 确认全局、忽略大小写、多行等修饰符符合业务需求
- 在长文本上测试一次，观察是否出现异常慢的匹配
- 记录表达式用途与测试样例，方便他人维护
与本站其他工具配合使用
完成正则测试后，可以把提取结果交给文本统计工具核对数量，也可以把需要进一步处理的 JSON、URL 参数先格式化再检查结构。开发联调时，先在本工具里确定日志提取规则，再到代码中按同一组样例验证，能够减少不同工具之间因编码或换行产生的差异。