工作原理
匹配由 JavaScript 自身的正则引擎驱动，也就是会在浏览器或 Node 中运行你这段模式的同一个引擎，所见即所得。这很重要，因为各引擎的差异很容易被忽略：后行断言在 JavaScript 和 PCRE 中可用，在 Go 的 RE2 中不可用；占有量词和原子组是 PCRE 独有的。如果生产代码运行在其他引擎上，在这里测试只能验证模式的逻辑，不能验证它的可移植性。
标志位对模式含义的影响超出多数人的预期。g 标志让引擎查找全部匹配而不是在首个匹配处停下，它的缺失正是 replace 经常只改掉一处的原因。i 让匹配忽略大小写；m 让 ^ 和 $ 匹配行边界而不是整串的首尾；s 让点号匹配换行；u 启用完整 Unicode 模式，此时字符类理解的是码点而不是 UTF-16 码元——这正是能否正确匹配一个 emoji 与只匹配到它一半的区别。
捕获组按左括号出现的顺序编号，嵌套组按“在哪里开始”而非“在哪里结束”编号。被量词修饰的组只捕获最后一次迭代的结果，这正是看起来应该捕获一串内容的模式却只返回一项的经典原因。使用 (?<name>...) 语法的命名组彻底绕开了计数问题，本工具会按名称连同位置一并列出，使模式与提取值之间的关系一目了然，而不必靠推断。
有两种失败模式值得明确警告。含有嵌套量词的模式，例如 (a+)+b，在遇到不匹配的输入时可能耗时呈指数增长，这就是灾难性回溯，当模式作用于用户输入时是真实的拒绝服务风险——30 个字符的字符串就足以让进程卡死。另一种是未加锚点的模式：\d{4} 会愉快地匹配更长数字的前四位，而加上 ^ 和 $ 往往才是本意。两者都会被报告出来，而不是留给你自己去踩。
常见应用场景
- 编写并调试邮箱、URL、电话号码或语义化版本号的校验模式。
- 针对真实日志样本编写提取字段的正则，而不是凭空猜测。
- 在编写读取代码之前，确认某个值落在了哪个捕获组里。
- 预览带反向引用的替换效果，确认输出格式后再应用到文件上。
- 在上线到服务器之前，检查模式是否存在灾难性回溯。
- 把难以阅读的模式转成自然语言解释，用于代码评审或注释。
最后更新: 2026-10-14