别让 lastIndex 坑了你：深入理解 JS exec 正则执行的潜规则

前端日常写正则，String.match() 通常够用了。但当你需要逐个提取复杂结构，或者处理超长文本流时，RegExp.exec() 才是那个隐藏的高手。很多开发者第一次接触它时，觉得和 match 差不多，直到在控制台发现匹配结果莫名跳跃，才意识到这里藏了个深坑。

这个陷阱的核心在于 正则对象的状态性。默认情况下，exec() 每次调用都会从字符串开头寻找匹配项，无论是否设置了全局标志。一旦加上 g 修饰符，它的行为模式就会彻底改变。它会记住上一次匹配结束的位置，保存在 lastIndex 属性中。下次调用时，直接从那个位置继续往后搜，而不是回到字符串头部。

这听起来是为了提升效率，但在实际业务逻辑里容易引发 Bug。比如你想遍历一段日志中的所有时间戳，如果忘记检查 lastIndex 的变化，可能会漏掉前面的数据，甚至陷入死循环。

来看一个典型的使用场景。假设我们需要从一个包含多个配置参数的长字符串中，逐个提取出键值对。这时候普通的 match 拿到所有结果后还得再解析索引，不如直接用 while 循环配合 exec：

const regex = /key=(\w+)/g;
const str = 'name=alice&key=bob&key=charlie';
let match;

while ((match = regex.exec(str)) !== null) {
  console.log(`找到：${match[1]}`);
}

这段代码看似标准，实则依赖两个关键点：一是正则必须带 g，二是 循环条件必须是 exec() 的返回值。只要正则对象被复用且携带了全局标志，它在内存中的 lastIndex 就是持久化的。这意味着同一个正则实例在不同地方混用时，状态可能互相干扰。

最棘手的情况是匹配到空字符串。如果正则允许匹配零长度内容，而 exec 刚好停在某个位置无法前进，lastIndex 就不会增加，导致下一次 exec 还在原地打转。为了避免这种 无限递归风险，资深开发者往往会在循环内部手动强制推进索引，或者优先选择 ES2020 引入的 String.prototype.matchAll()。

对比一下两者的区别会更清晰。match() 方法在遇到 g 标志时直接返回所有匹配结果的数组，适合一次性获取全部数据；而 exec() 则是一次只吐出一个结果对象，更适合流式处理或需要在匹配过程中打断逻辑的场景。如果你需要在发现某个关键字后立即停止后续搜索，用 break 跳出 exec 循环显然比生成完整数组后再筛选要节省内存。

另外要注意捕获组的返回值结构。exec 返回的数组中，result[0] 是整个匹配的字符串，result[1] 开始才是括号内的捕获组。更重要的是，这个数组上挂载着 index 属性记录起始位置，以及 input 属性记录原字符串。在处理文本替换或高亮时，利用这两个属性能省去大量额外计算。

说到底，exec 就像一把双刃剑。它提供了比 match 更底层的控制力，尤其是对于需要精细控制匹配位置的复杂算法。但对于简单的查找统计，它多出来的状态管理反而成了负担。在使用前问自己一句：我真的需要它记忆上次匹配位置吗？如果不需要，清除正则上的 g 标志是最稳妥的做法，或者直接创建一个新的正则实例来隔离状态。

掌握 lastIndex 的行为机制，能让你在调试正则相关 Bug 时少浪费半天时间。工具没有优劣，只有适用场景不同。理解它背后的状态流转，才能在写出高效代码的同时，避开那些看不见的逻辑陷阱。