正则表达式测试与调试工具

就是你浏览器中已经在运行的那一种。本页没有打包任何引擎：你的模式会直接交给 JavaScript 运行时自带的 RegExp 构造函数，你看到的匹配就是你的代码会得到的匹配。因此结果对 JavaScript、TypeScript、Node、Deno 和 Bun 完全准确，对其他环境则只是近似。Python 的 re、PHP 和 Perl 中的 PCRE、Go 的 RE2、Rust 的 regex crate、.NET、Java、grep、sed 和 ripgrep 都有差异，有时在语法上，有时在同一语法的含义上。如果模式要用在其他语言中，上线前请在那里再测试一遍。

贪婪量词会尽可能多地匹配，然后一次退回一个字符，直到模式的其余部分能够匹配。惰性量词（在后面加一个问号，即 *? +? ?? {n,m}?）会尽可能少地匹配，只有在不得不时才扩展。经典示例是用 /<.+>/ 匹配“<a><b>”：贪婪的 .+ 会一路吞到末尾，再回溯到最后一个“>”，把“<a><b>”作为一个整体匹配返回。改成 /<.+?>/，你会依次得到“<a>”和“<b>”。两者没有谁更正确，它们回答的是不同的问题。实用的规则是：分隔符唯一时，默认用贪婪；分隔符会重复时，默认用惰性。

当一个模式可以用许多种方式切分同一段文本，而最终匹配又失败时，就会发生灾难性回溯。JavaScript 通过回溯进行匹配，所以失败时会把剩下的每一种组合都试一遍才放弃。教科书式的诱因是重复里面套重复，例如用 /(a+)+$/ 匹配一长串“a”后面跟一个“b”。把 30 个 a 分成若干个至少含一个字符的组，方法数量呈指数级增长，引擎会全部试完才断定“$”无法匹配。三十个字符只需几毫秒；四十个字符大约要慢一千倍。解决办法包括：让内外两层重复无法匹配相同的文本，用字符类替换带量词的分组，或者给模式加上锚点以便尽早发现失败。本页会在运行前扫描你的模式中是否存在这些结构，并指出它们。

先行断言从一开始就存在于语言中，但后行断言直到 ES2018 才加入（晚了二十多年），而在 Safari 于 2023 年支持之前，使用它的模式会在一个许多网站仍需支持的浏览器上抛出语法错误。这一延迟部分源于从 ES4 被放弃到 ES6 之间语言演进的整体放缓，部分则因为后行断言确实更难实现：引擎必须从当前位置向后匹配。JavaScript 的实现最终比大多数引擎都好，因为与 PCRE、Python 的 re 和 Java 不同，它允许变长后行断言。/(?<=\$\d+ )item/ 在这里是合法的，在那些引擎里则会被直接拒绝。如果你的模式需要在旧环境中运行，传统的变通办法是用一个分组捕获前面的上下文，事后再丢弃。

u 标志来自 ES2015，会让模式进入 Unicode 模式：emoji 等辅助平面字符算作一个单位，而不是两个 UTF-16 半部分；\u{1F600} 变为合法；\p{…} 属性转义被启用；没有意义的转义会变成语法错误，而不是被悄悄忽略。v 标志来自 ES2024，是 u 的超集，在字符类中加入了集合表示法（用 -- 求差集，用 && 求交集，以及多字符字符串属性），因此你可以写 [\p{Letter}--[a-z]] 来表示“除 ASCII 小写字母外的任意字母”。这两个标志互斥：一个正则要么是 u 模式，要么是 v 模式，不可能两者兼有。本页提供 u 而不提供 v，因为一对会悄悄互相抵消的按钮，不如一个如实说明自身范围的界面。

因为带有 g 或 y 标志的正则是有状态的。它保存一个 lastIndex 属性，exec 和 test 都从那里开始，并在成功时更新它。把这样一个正则存进模块级常量，对同一个字符串调用两次 test，第二次就会从中途开始并返回 false。在循环中对多个条目复用全局正则时，同样的问题也会出现。解决办法有三种：在使用处重新创建正则，每次调用前把 lastIndex 重置为 0，或者改用 matchAll 和 String.match，它们不会把光标留在可能绊倒你的地方。本页每次运行都会编译一个私有的工作副本，从而彻底绕开这个问题，所以你看到的正则永远不是被修改的那一个。

有好几项，知道是哪些，可以在你跨引擎复制模式时省去大量令人困惑的调试。没有原子组：PCRE 的 (?>…) 会锁定一次匹配并拒绝回溯进去，这是手动修复灾难性回溯的标准做法，而 JavaScript 唯一的替代方案是用先行断言包住一个捕获。出于同样的原因，也没有占有量词（a*+）。没有递归 (?R)，也没有子程序调用，所以平衡括号无法匹配。没有内联修饰符：在模式中间写 (?i) 是语法错误，因为 JavaScript 的标志要么作用于整个正则，要么完全不起作用。没有条件分支，没有 \A \z \Z 锚点，没有 [[:alpha:]] 这样的 POSIX 字符类，也没有注释模式。而 JavaScript 拥有、许多引擎却没有的，是变长后行断言。

不一样，而且这种差异是安全漏洞的真实来源。在 JavaScript 中，\d 永远恰好等于 [0-9]，无论有没有 u 标志。在 .NET 和 Python 3 中，\d 默认匹配任何具有 Unicode 十进制数字属性的字符，包括阿拉伯-印度数字 ٠١٢、天城文数字和全角数字 ０１２。一个用 Python 编写、接受 ٢٠٢٦ 的校验器，和一个用 JavaScript 编写、拒绝它的校验器，会对同一输入得出不同结论，而这正是会被利用的那种不一致。同样的提醒也适用于 \w，它在这里是 [A-Za-z0-9_]，因此不把“é”视为单词字符；也适用于 \b，它是根据 \w 定义的，所以会落在“naïve”的中间。如果你想在 JavaScript 中使用 Unicode 语义，必须显式要求：数字用带 u 标志的 \p{Nd}，字母用 \p{L}。

当你要匹配的东西可以嵌套时。形式意义上的正则表达式不会计数，虽然反向引用让 JavaScript 的引擎超出了严格的正则语言，但它仍然无法匹配平衡结构。这就排除了 HTML、XML、JSON、源代码以及任何带括号的语言，不是因为模式难写，而是因为根本不存在这样的模式。请使用 DOMParser、JSON.parse 或真正的解析器。还有三个较温和的信号指向同一方向：模式已经超过一两行，没人能读懂；每个子句都需要注释来解释；或者它不断为本应早已处理好的输入添加特殊情况。正则表达式最擅长查找和校验扁平、结构规整的片段（日期、十六进制颜色、日志前缀），最不擅长的是假装自己是一套语法。

它们是 String.replace 在替换字符串中能识别的替换模式。$1 到 $99 插入对应编号捕获组的文本，$<name> 对命名组做同样的事。$& 插入整个匹配。$` 插入匹配之前的所有内容，$' 插入匹配之后的所有内容；两者在包裹文本时出奇地有用，也出奇地容易被意外触发，因为反斜杠无法转义它们。$$ 插入一个字面意义的美元符号。有两条规则常让人措手不及：引用不存在的分组时，不会抛出错误，而是作为普通文本留在输出中；如果模式有十二个分组，$12 表示第 12 组，否则表示第 1 组后跟字符“2”。本页会在预览中展开所有这些写法，并标出无法解析的引用。