正则表达式

是什么，为什么存在

正则表达式通常简称 regex，它描述一组文本序列。正则引擎尝试让模式匹配输入字符串，并报告是否匹配以及匹配位置。带括号的分组还可以提取选定子串，交给后续代码使用。

正则表达式很简洁，因为一段模式能把字面文本与选择、重复、边界和字符类运算符组合在一起。它适合处理具有局部规则形状的文本，例如标识符、日志前缀、文档中的词元或机械改写。正是这种高密度表达能力，让未说明的契约也很容易藏在模式里。

四种常见任务使用同一个引擎，但成功标准各不相同：

捕获组（capturing group） 会记录某段括号模式所消费的子串。(?<year>\d{4}) 这样的命名组比编号组更容易审查，尤其适合仍会变化的模式。若括号只用于控制选择或重复，应使用非捕获组 (?:...)。

正则表达式识别的是形状，不是领域事实。月份片段可以把文本限制在 01 到 12，但能接受 2025-02-29 的模式并没有验证日历。应先用正则建立安全且有用的形状，再由普通代码解析并验证语义规则。

正则语法存在多种方言，并非一种通用语言。本主题使用 Node 24 上的 ECMAScript 正则表达式。来自 PCRE、Python、Java 或线性时间引擎的构造可能不存在，也可能具有不同的转义、Unicode、锚点和替换行为。

工作原理

引擎接收模式、标志、输入字符串，通常还会接收起始位置。它在模式中寻找一条能按顺序消费输入的路径。成功时返回整体范围和捕获内容；失败时，调用 API 返回 null 或 false。

阅读模式时应从外到内。先识别锚点和标志，再看顶层选择，随后分析分组，最后检查各原子所带的量词。这个顺序能揭示模式是在搜索子串，还是声称校验整个输入。

原子、选择与数量

原子会消费一个单位，或者断言某个位置。字面量 A、字符类 [A-Z]、转义 \d、通配符 . 与括号分组都是常见原子。^、$、\b 或环视等断言只检查位置，不消费文本。

量词只作用于它紧前面的原子：

贪婪与惰性描述的是引擎先尝试哪个候选长度，不是安全保证。模式后部失败时，贪婪量词可以交还字符；出于同样原因，惰性量词也可以反复扩展。

选择运算 left|right 会在候选起点按源码顺序尝试各分支。括号决定它的作用范围：cat|dog food 与 (?:cat|dog) food 含义不同。若分支重叠，即使两种形式都报告匹配，其顺序也可能改变捕获结果。

捕获与匹配结果

整体匹配位于结果元素 0。编号捕获按照左括号出现顺序排列，命名捕获则位于 match.groups 中。某个分组在量词下多次参与匹配时，通常只保留最后一次捕获的子串。

可选分组可能产生 undefined。后续代码不能假定每个声明过的分组都参与了匹配。若代码只需判断结构是否存在，应把结构性分组设为非捕获，让捕获结果保持精简且意图明确。

模式中的 \1 或 \k<name> 等反向引用要求后续输入等于先前捕获。替换 API 在匹配完成后解释的 $1 和 $<name> 则属于替换引用。审查时很容易混淆这两个上下文。

标志与状态

标志会改变模式语言和搜索过程。u 会启用 Unicode 感知的解析方式，并让若干构造按码点处理。i 忽略大小写，m 改变行锚点行为，s 允许点号匹配行终止符，g 执行全局迭代，y 则要求匹配必须从 lastIndex 开始。

g 与 y 标志会让 RegExp 对象通过 lastIndex 携带状态。调用 exec() 或 test() 可能推进或重置该属性。因此，把同一个全局对象复用为校验器，会让两个相同的有效输入交替得到 true 和 false。

应根据所需结果选择 API：

两层转义

JavaScript 会把 /\d+/u 这样的正则字面量直接解析成正则语法。传给 new RegExp("\\d+", "u") 的字符串先按 JavaScript 字符串解析，再按正则语法解析。双反斜杠属于字符串层，并不表示另一种正则含义。

动态文本是数据，不是正则源码。在 Node 24 中，RegExp.escape(userText) 会把任意字面片段转换为可安全嵌入较大模式的源码。只靠手工转义点号和星号，会漏掉其他标点及依赖上下文的情况。

Unicode 契约

JavaScript 字符串使用 UTF-16 代码单元。启用 u 后，点号与若干正则操作会把表示一个码点的代理项对视为一个单位，但仍不能识别用户感知的完整字素簇。组合序列或连接 emoji 可以包含多个码点。

即使启用 u，ECMAScript 中的简写 \d 仍只匹配 ASCII 数字。若契约允许其他书写系统的十进制数字，应结合 u 使用 \p{Decimal_Number}，并确认后续数值解析是否支持它们。若契约本来就是 ASCII 协议词元，\d 反而可能完全正确。

\p{Script=Greek} 等 Unicode 属性转义比大段复制的范围更清楚地表达字符意图。它们要求 Unicode 感知模式，但仍需测试组合标记、规范化形式和混合书写系统输入。正则匹配不会自动规范化文本。

示例

以下示例依次展示完整输入校验、搜索、基于捕获的替换，以及经过测量的对抗行为。下面每段输出都来自 Node v24.14.0 实际执行对应文件的结果。

校验并解析订单引用

第一段模式匹配前缀，并捕获两个命名字段。函数另外要求匹配范围与完整输入相等，因此会拒绝有效前缀之后仍有其他文本的情况。

把编号保留为文本可以保存前导零。若应用随后要把它转换为数值，这项转换属于另一份契约。正则表达式也没有断言所引用的订单确实存在。

JavaScript 的 $ 断言还可以在末尾行终止符之前匹配，因此只用 ^...$ 很容易被夸大成绝对完整消费。把整体匹配与原输入比较，能明确表达预期边界。另一种设计可以先拒绝行终止符，再使用经过仔细说明的锚点策略。

用命名捕获寻找告警

这里的 m 让 ^ 与 $ 在行边界工作，g 则找出每一个匹配行。matchAll() 会返回匹配索引和命名组，无需手写 exec() 循环。

const log = [
  "2026-09-04T10:30:00Z [INFO] worker started",
  "2026-09-04T10:31:08Z [WARN] queue depth is 42",
  "2026-09-04T10:31:11Z [ERROR] payment timed out",
].join("\n");

const alertPattern =
  /^(?<time>\S+) \[(?<level>WARN|ERROR)\] (?<message>.+)$/gmu;

for (const match of log.matchAll(alertPattern)) {
  const { time, level, message } = match.groups;
  console.log(`${level} at ${time}: ${message}`);
  console.log(`  match starts at index ${match.index}`);
}

WARN at 2026-09-04T10:31:08Z: queue depth is 42
  match starts at index 43
ERROR at 2026-09-04T10:31:11Z: payment timed out
  match starts at index 89

这段模式只识别当前任务需要的日志外壳。\S+ 不是时间戳校验器，.+ 也有意把消息解释留给后续代码。只有当消费方确实存在规则时，才应进一步收窄字段。

索引采用 UTF-16 代码单元偏移，因为 JavaScript 就用这种方式索引字符串。它们适合对同一个字符串调用 slice()，但不能自动当作 UTF-8 文件的字节偏移或用户看到的列号。

用回调替换匹配项

这个示例寻找两个带格式的 16 位数字序列，并利用命名捕获只保留首尾两组。回调会显式构造替换结果，避免替换模板中的特殊 $ 序列产生歧义。

const note = [
  "primary=4111 1111 1111 1111",
  "backup=5555-4444-3333-2222",
  "reference=20260904",
].join("; ");

const cardPattern =
  /(?<!\d)(?<first>\d{4})[ -]?\d{4}[ -]?\d{4}[ -]?(?<last>\d{4})(?!\d)/gu;

let replacements = 0;
const redacted = note.replace(cardPattern, (...arguments_) => {
  const groups = arguments_.at(-1);
  replacements += 1;
  return `${groups.first}-••••-••••-${groups.last}`;
});

console.log(redacted);
console.log(`replacements=${replacements}`);

primary=4111-••••-••••-1111; backup=5555-••••-••••-2222; reference=20260904
replacements=2

后行断言与先行断言检查数字边界，但不消费相邻文本。八位引用无法满足完整的 16 位形状，因此保持不变。若模式包含命名捕获，回调最后一个参数就是命名组对象。

这只是格式处理演示，不是完整的支付数据控制。真实系统应避免接收不需要的卡片数据，在文本进入通用日志之前执行存储与日志策略，并测试所有受支持输入格式。数据已经写入日志后再脱敏为时已晚。

测量有歧义的重复

嵌套模式可以用多种方式切分同一串 a，最后的 ! 才会证明匹配失败。有界模式则直接表达示例的真实策略：只能包含一到 24 个 a，不能有其他内容。

const nestedPattern = /^(a+)+$/u;
const boundedPattern = /^a{1,24}$/u;

for (const size of [12, 16, 20, 24]) {
  const adversarial = `${"a".repeat(size)}!`;
  const started = performance.now();
  const nestedMatch = nestedPattern.test(adversarial);
  const elapsed = performance.now() - started;
  const boundedMatch = boundedPattern.test(adversarial);

  console.log(
    `${adversarial.length} chars: nested=${nestedMatch} ` +
      `${elapsed.toFixed(3)}ms, bounded=${boundedMatch}`,
  );
}

13 chars: nested=false 0.156ms, bounded=false
17 chars: nested=false 0.335ms, bounded=false
21 chars: nested=false 4.683ms, bounded=false
25 chars: nested=false 73.597ms, bounded=false

这些数据来自审查机器上的一次 Node 24 运行，不是可移植的基准常量。关键证据是失败案例，以及每增加四个字符时迅速增长的工作量。生产测试应执行宽松且适合具体机器的预算，不应断言这些精确毫秒数。

有界表达式还通过执行 24 字符策略改变了所接受的语言。若真正需要任意长度，应采用最坏情况边界可靠的构造或引擎，而不是隐藏上限。绝不能用无界输入运行有意设计的危险基准。

陷阱

把形状当作含义

修复方法： 用正则处理有文档说明的词法边界，再通过领域 API 解析并执行语义检查。测试一个形状有效但含义无效的值，例如不存在的日历日期，避免混淆两个阶段。

只校验子串

修复方法： 比较整体匹配范围与完整输入，或者使用经过明确审查的绝对边界构造。校验正则不要带 g 与 y，并加入前导文本、尾随文本和末尾换行符案例。

混淆源码与字面数据

修复方法： 固定模式应写成正则字面量。确实需要动态组合时，在 Node 24 上让字面片段先经过 RegExp.escape()，把可信正则源码与数据分开，并测试 .、-、(、] 和 \ 等标点。

假定只有一种字符含义

修复方法： 在需求中明确单位与字符范围：ASCII 数字、Unicode 十进制数字、码点、字素、字节或 UTF-16 代码单元。契约需要时使用 Unicode 属性转义与 Intl.Segmenter，并把规范化作为单独策略处理。

编写有歧义的重复选择

修复方法： 消除有歧义的嵌套，提取公共前缀，并明确限制输入与重复次数。在隔离测试进程中，于截止时间内执行长近似失败案例；面对外部可达的复杂模式，可考虑解析器或具有合适最坏情况保证的引擎。

信任全局正则状态

修复方法： 单次校验不要使用有状态标志；完整迭代优先使用 matchAll()；也可以只控制一个明确的 exec() 循环，并处理零长度行为。不要把 test() 当作真正需要捕获内容的 exec() 的预检。

延伸阅读

• ECMAScript 规范：RegExp 对象
• MDN：正则表达式指南
• MDN：RegExp 参考
• MDN：Unicode 字符类转义
• OWASP：正则表达式拒绝服务