Contact alice@example.com or bob@test.org for details, or admin@site.io
alice@example.com@ 8–25aliceexample.combob@test.org@ 29–41bobtest.orgadmin@site.io@ 58–71adminsite.io关于 正则表达式测试器
写正则最怕的是「看起来对，但总在某些输入上不对」：校验表单时放过了不该放过的、抓取日志时漏掉了变体写法、替换时把不该改的地方也改了。正则测试工具的用途就是把「想想对不对」变成「当场看到匹配到哪里」，用高亮和分组结果替代反复试错。 它的原理是把你写的表达式交给浏览器原生的正则引擎执行，实时标出全部匹配片段与捕获组。因为用的是同一套引擎，你在工具里看到的行为与代码里一致——这一点比很多在线的其他语言正则实现更可靠，但也意味着只看它不能替代对目标语言引擎差异的判断。 使用要点：先打开全局标志，否则只会高亮第一处匹配，容易误判表达式「只匹配到一次」；需要看分组时用命名分组，让捕获结果自带标签而不是靠数括号；测试集必须包含反例——只测能通过的样本无法发现过度宽松的问题，建议至少准备「应当匹配」「不应当匹配」「边界情况（空串、超长、含换行）」三组。调优顺序上，先把功能写对，再考虑性能。 边界与限制：不同语言的引擎有实质差异，语法与行为不能互相假定：点号默认是否匹配换行、是否有回溯与占有量词、 的判定范围都不相同，把一个语言里验证通过的表达式搬到另一个语言必须重新验证。最需要警惕的是灾难性回溯：形如 (a+)+b 的嵌套量词在长串不匹配时会引起指数级回溯，几百个字符就能把进程的 CPU 打满，生产环境应避免这类结构或改用更明确的字符类。此外正则不适合解析嵌套结构（HTML、JSON），这类任务应交给专用解析器。 数据与隐私：人们测试正则时习惯直接粘贴真实日志、包含手机号的表格或用户输入样本。这些内容一旦上传就可能被留存。本工具使用浏览器内置引擎在本地执行，输入不离开设备，断网后依然可用。
跨引擎差异与可维护性上有几条必须记住的清单。JavaScript 里点号默认不匹配换行，需要 s 标志；Python 需要在编译时传 re.S；Java 默认同样不跨行，但提供了 DOTALL 内联开关。环视（lookahead、lookbehind）在多数现代引擎可用，但 lookbehind 的可变长度支持并不一致，只有部分引擎允许。命名分组与反向引用的语法在 JavaScript、Python、.NET 之间写法各不相同（(?P<name>) 与 (?<name>) 不能互换）。可维护性方面，超过一屏的正则应当拆分成具名片段并通过字符串拼接组装，再用注释说明每一段在匹配什么；在业务代码里保留一段无人能读懂的表达式，维护成本会随着人员流动迅速上升，必要时用解析函数替代正则反而是更清晰的选择。
最后区分正则与通配符：glob（如 *.log、src/**/*.ts）只做文件名或路径匹配，语义简单且不可移植到文本搜索，但它没有回溯风险；把 glob 的直觉套到正则上（例如以为 * 可以单独表示「任意多个字符」）是初学者最常见的误解之一。 对于只做一次的数据清洗，先把样本导出到本地用脚本验证，往往比在网页工具里反复试错更快也更可复现。
实现原理
正则引擎在文本上尝试匹配时，会从左到右推进并回溯。回溯是能力的来源——它让 a+b 能匹配任意数量的 a——也是性能问题的来源：嵌套量词（如 (a+)+b）在长串不匹配时会产生指数级的尝试次数。「贪婪」与「懒惰」只改变匹配长度，不改变能否匹配。
/(\d{4})-(\d{2})/g 作用于 "2026-10 与 2027-03"两次匹配，分组分别为 ("2026","10") 与 ("2027","03")使用方法
- 打开正则测试工具
- 在「正则」输入框中输入正则表达式
- 在「测试文本」区域输入要匹配的文本
- 查看高亮匹配结果和匹配列表
- 使用替换模式进行文本替换
使用场景
- 验证表单输入 — 调试邮箱、手机号、URL、密码强度等校验正则。
- 日志提取 — 从大段日志里抓取时间戳、错误码、IP 地址等字段。
- 批量替换 — 配合编辑器的"正则替换"功能，调好正则再批量改代码。
- 爬虫数据清洗 — 从抓取的 HTML 里提取价格、标题、评分等结构化数据。
- 学习语法 — 一边改正则一边看高亮结果，比看文档学得快。
常见问题
本工具用的是哪个正则方言？
JavaScript / ECMAScript 方言（PCRE 的子集）。常见差异：不支持反向引用 \g、原子组 (?>)、平衡组等高级特性。Python re 模块的语法绝大部分通用。
为什么我的正则匹配不到？
最常见原因：(1) 漏了 g 标志只匹配第一个；(2) 特殊字符 . * ? + 没转义；(3) 多行文本用了 ^/$ 但没加 m 标志。
正则会不会有性能问题？
会。嵌套量词（如 (a+)+）配上失败匹配会触发"灾难性回溯"，导致页面卡死。本工具用浏览器原生引擎，超时会自动中断。
想测试 grep 或 sed 的正则怎么办？
它们用 BRE/ERE 方言，部分元字符需要转义（如 \(\)）。本工具不完全兼容，复杂场景建议直接在终端测试。
怎么记住常用正则？
可以参考本站的「正则速查」工具，里面整理了邮箱、URL、IP、信用卡等常用模式。
为什么 ? 号匹配到的不是我想要的字符？
问号在正则里有两种含义：单独跟在字符后面表示「前面的字符出现 0 或 1 次」（如 colou?r 同时匹配 color 和 colour），跟在量词 * + ? 后面则表示「非贪婪」，让匹配尽量短。如果你想要的其实是「可选的整段字符」，直接用 ? 往往作用范围不对。正确做法是先把要变成可选的字符串包进分组，如 (https?://)?，若不想捕获该分组就用非捕获分组 (?:...)?。把它套在括号外再测，就只会影响括号内的整段，而不是紧邻的单个字符。
为什么 . 匹配不到换行符？
默认情况下点号 . 匹配除换行符之外的任意字符，所以遇到多行文本、. 会在一行结束时停下。解决方式有三种：给正则加 s 标志（单行模式），让 . 也能匹配换行；或者改用 [\s\S] 来同时匹配空白和非空白；也可以显式写 [^\n] 但这样仍不含换行。若是要跨多行匹配「块」，推荐 s 标志配合 .*? 非贪婪使用，先在「测试文本」里放入真实的多行日志再确认结果。
匹配结果和线上代码运行的不一致？
先对齐两件事：正则引擎的差异（JS 与 PCRE 在 lookbehind、命名组上支持不同）；标志位差异（g 标志会让 lastIndex 状态影响连续匹配）。把测试工具的标志位设置成与线上一致，再用同一份输入验证。