正则表达式测试器该有哪些功能：一次 40,000 个匹配的实测，和五个会静默骗人的默认值

绝大多数在线正则测试器长得一样：一个 pattern 输入框，一个测试文本，匹配部分标黄。这个形态能用，但它把正则最容易出错的几件事全部藏了起来——同一个 pattern 连测两次结果不同、替换文本里的 $1 被吃掉、一个 emoji 被算成两个字符、26 个 a 就让页面卡死七秒。下面所有数字来自本机实测，环境是 Windows 11、Node 24.12.0、Python 3.13.14。

一、别复用带 g 的 RegExp 对象

这是写测试器时第一个会踩的坑，也是唯一一个"结果取决于你敲了几个字"的 bug。把 /a/g 这一个对象连续 test('aaa') 十轮：

结果: T T T F T T T F T T
false 次数: 2 / 10

lastIndex 会跨调用保留：第 1 轮匹配到下标 1，第 2 轮从 1 开始，第 3 轮到末尾，第 4 轮归零后返回 false。测试器每次按键重算，如果缓存了编译结果，用户看到的匹配数就会在 3 和 2 之间跳。

更隐蔽的是 exec 循环被污染。先 test 一次，再跑 while (m = re.exec(s))：

const re = /\w+/g, s = 'ab cd ef';
re.test(s);                    // lastIndex 变成 2
// 循环只拿到 ["cd", "ef"]，第一个 "ab" 永久丢失

期望 3 个，实际 2 个，没有报错。所以匹配入口必须每次新建对象，并且零宽匹配要手动前进游标：

function runAll(pattern, flags, text) {
  const re = new RegExp(pattern, flags);      // 每次新建，lastIndex 从 0 开始
  const out = [];
  let m;
  while ((m = re.exec(text)) !== null) {
    out.push({
      start: m.index,
      end: m.index + m[0].length,
      groups: m.slice(1),
      named: m.groups ?? {},
    });
    if (m[0] === '') re.lastIndex++;           // 不前进就是死循环
  }
  return out;
}

二、空匹配必须画出来

'bbb'.match(/a*/g) 返回 ["", "", "", ""]，四个空串。Python 侧 re.sub(r'a*', 'X', 'bbb') 得到 XbXbXbX——四个 X，分别插在三个字符之间的四个位置上。用户看到"没有匹配"，替换结果却多了四个字符，这是最难解释的一类困惑。

测试器如果只标黄非空区间，这一整类行为就不可见。正确做法是把零宽匹配渲染成光标位置的竖线标记，并在列表里显式写 len=0 @3。同样的道理适用于重叠匹配：'ababa'.match(/aba/g) 只有 1 个，加前瞻 (?=(aba)) 才有 2 个。不提供"允许重叠"开关，用户会以为引擎漏了。

三、. 不是"一个字符"

'😀'.length              → 2
/^.$/.test('😀')         → false
/^.$/u.test('😀')        → true
'😀'.match(/./g)         → ["\ud83d", "\ude00"]
'👨‍👩‍👧'.length            → 8        [...s].length → 5

而汉字 '中'.length 是 1，/^.$/ 照样通过。也就是说这个坑只在 emoji 上暴露，中文测试永远发现不了。用 /^.{1,20}$/ 校验昵称时，20 个 emoji 会被判成 40 个字符直接拒绝，用户只知道"名字填不进去"。

所以测试器至少要同时给出三个计数：UTF-16 码元数（s.length）、码点数（[...s].length）、字素簇数（Intl.Segmenter）。三者不一致时提示用户"这条正则按码元工作"。

四、\w、\d、\p{L} 在三个引擎里是三种语言

同一份"用户名只允许字母数字下划线"的规则，换引擎就是换语义：

Python 的 \w 默认是 Unicode 语义，加 re.ASCII 才收窄到 ASCII——实测加 re.ASCII 后中文与 ٣ 均返回 false。JS 侧即使加了 u，\w 也只是 ASCII 加下划线。最危险的是 /\p{L}/ 忘记 u：它会把 p{L} 当成字面量去匹配，/\p{L}/.test('p{L}') 返回 true，不报错。

一个测试器如果不带引擎选择器，用户就会拿 Python 验证通过的正则去写前端校验，或者反过来。所以引擎切换不只是"换执行器"，还要在标签上直接标注差异——比如让用户看到"这条在 Python 通过、在 JS 拒绝"。

五、替换预览不能只给结果

$1 和 \1 是两套语法，而且失败方式完全不同：

'2026-11-06'.replace(/(\d+)-(\d+)-(\d+)/, '$3/$2/$1')   // "06/11/2026"
'abc'.replace(/b/, '[$&]')                              // "a[b]c"
'abc'.replace(/(b)/, '$$1')                             // "a$1c"
'ab'.replace(/(a)(b)/, '[$10]')                         // "[a0]"  ← 只有两个分组
'abc'.replace(/b/, "[$`|$']")                           // "a[a|c]c"  ← 插入了前后缀

$10 在只有两个分组时不会报错，它退化成 $1 加一个字面量 0，输出 [a0] 看上去还挺合理。$`` 和 $'` 更狠，直接把匹配前后的整段文本插进来。

Python 侧则是另一种失败：re.sub(r'(\d+)-(\d+)-(\d+)', r'$1', '2026-11-06') 原样返回 '$1'，静默无效；而 r'\10' 在只有一个分组时直接抛 re.PatternError: invalid group reference 10 at position 2。JS 静默降级、Python 直接报错，两种都不能靠肉眼发现。

测试器要做的不是"跑一遍替换"，而是把替换串按当前引擎的语法拆成 token 展示：哪几段是分组引用、哪几段是字面量、有没有引用不存在的分组。这个面板比结果本身有用。

六、$ 的位置在 CRLF 上不一样

同一条 ^(.+)$，同一段 'a\r\nb\r\n'：

JS   /^(.+)$/gm        → ["a", "b"]
Py   re.findall(..., re.M) → ['a\r', 'b\r']   长度 [2, 2]

原因是 Python 的 . 匹配 \r，而 $ 只认 \n 之前的位置，于是 \r 被吞进捕获组；JS 的 . 把 \r 算作行终止符，$ 也能在 \r 前匹配。这条差异在界面上表现为：高亮区域末尾多了一个看不见的字符，用户复制分组内容入库，字段里就带了一个 \r，后续比对全部失败。

因此控制字符必须可见：\r 渲染成 ␍，\n 渲染成 ␊，并在每个匹配上显示 start..end 的偏移量。只标黄不报偏移的测试器，在排查这类问题时等于没有信息。

七、给匹配加超时，否则 26 个字符就能卡死

(a+)+b 对 'a'.repeat(n) + 'c' 的耗时，每组 5 次取最小值：

每加 2 个字符约 4 倍。26 个 a 在 Python 里要 7.9 秒，JS 也要 1.5 秒。这里有个测试方法上的坑：第一轮我没预热，测出 n=18 用 51.4 ms、n=20 反而只要 24.4 ms，曲线是乱的——JIT 把首次调用的编译成本算进去了。改成每组跑 5 次取最小值，才出现干净的指数曲线。

关键问题是两个引擎都没有超时参数：Python 的 re 没有 timeout，JS 主线程上的 RegExp 也无法中断。所以"复杂度过高"只能由测试器自己兜：匹配跑在 Web Worker 里，超过 200 ms 直接 terminate() 并提示"该模式存在回溯风险"；同时对 (a+)+、(a|a)*、(.*)* 这类嵌套量词做静态预警。

八、性能预算：引擎不是瓶颈

38 万字符的文本、40,000 个匹配，纯扫描耗时 JS 2.0 ms、Python 16–26 ms。也就是说正则引擎根本不是瓶颈，真正贵的是把 40,000 个匹配变成 40,000 个 <mark> 节点。所以测试器必须给高亮设上限（比如前 2,000 个），其余用计数呈现；或者干脆用一层绝对定位的叠加层画，避免每次按键重建 DOM。

结论

正则测试器的价值不在"能高亮"，而在于它能不能证明"你看到的结果和目标引擎跑出来的一致"。为此需要四样东西：每个匹配的精确偏移、空匹配与重叠匹配的显式呈现、引擎差异的可见标注、以及一个真正能被打断的执行环境。少任何一样，工具给出的都只是一个看起来对的答案。