JavaScript matchAll 的游标副本：遍历已到末尾，原正则的位置为什么没动
把exec循环换成matchAll以后，匹配结果已经读到最后，原正则的lastIndex却仍停在一。接着重新调用，又从同一个非零位置开始。这种行为来自matchAll为普通正则创建匹配副本：它保留创建时的起点，遍历推进的是内部副本。原对象没有被推进，不代表扫描从零开始；不理解这两个事实，就可能让复用正则的搜索漏掉开头命中。
本文在Linux与Node.js v24.19.0上实跑，使用普通原生RegExp对象和固定ASCII字符串。没有自定义Symbol.matchAll、RegExp子类或浏览器界面依赖；特殊可扩展对象应依据各自协议另行测试。
AI生成的概念示意图：原始文本标尺与半透明副本并列，原标记保持不动，放大镜沿副本前进，表示复制起点后独立扫描；不是真实软件界面或运行截图。
完整程序与实际输出
保存为demo.mjs，执行node demo.mjs。程序只使用固定测试输入，代码和本次输出分别列出。
const text = 'a a a';
const pattern = /a/g;
pattern.lastIndex = 1;
const iterator = text.matchAll(pattern);
console.log('original before:', pattern.lastIndex);
console.log('matches:', JSON.stringify([...iterator].map(m => [m[0], m.index])));
console.log('original after:', pattern.lastIndex);
console.log('same iterator again:', JSON.stringify([...iterator]));
pattern.lastIndex = 1;
const snapshot = text.matchAll(pattern);
pattern.lastIndex = 0;
console.log('changed original:', pattern.lastIndex);
console.log('snapshot positions:', JSON.stringify([...snapshot].map(m => m.index)));
console.log('fresh positions:', JSON.stringify([...text.matchAll(pattern)].map(m => m.index)));
try {
text.matchAll(/a/);
} catch (error) {
console.log('without g:', error.name);
}本次实际标准输出：
original before: 1 matches: [["a",2],["a",4]] original after: 1 same iterator again: [] changed original: 0 snapshot positions: [2,4] fresh positions: [0,2,4] without g: TypeError
先把起点设成一个不会直接命中的位置
字符串a空格a空格a的三个字母索引分别为零、二、四。pattern是带g标志的/a/，程序先把lastIndex设为一，再创建matchAll迭代器。一位于空格处，但普通全局匹配可以继续向后搜索，因此结果是索引二与四的两个a，开头索引零不在此次搜索范围内。
遍历前后原pattern.lastIndex都打印为一。这与直接调用会更新lastIndex的exec方式形成区别：matchAll内部推进自己的匹配状态，不需要在每次取得结果后把新游标写回原对象。可以安全读完这一轮结果，却不能把原正则的位置当作本轮扫描进度条。
如果调用者的需求是每次搜索完整字符串，就应在创建过程前明确设置起点，或使用专属于本次搜索的新正则。不要因为matchAll“不改原对象”，就推断它“忽略原对象的起点”。保留状态与读取状态是两件事，原lastIndex仍然参与初始化。
起点在创建时复制，不随原对象后来改变
第二组先把原正则设为一，创建snapshot，再把原lastIndex改成零。随后消费snapshot，得到的索引仍是二与四。这表明迭代器沿用创建时复制的起点，而不是每次next都重新读取原对象当前的lastIndex。创建与消费之间的修改不会让已创建的普通匹配副本倒回开头。
紧接着使用同一个已被设为零的pattern新建一轮matchAll，结果包含零、二、四。新旧两轮不同，不是字符串发生改变，而是创建时起点不同。这个对照非常适合排查异步代码：一个迭代器可能很早创建，却很晚才消费，调试时只查看当前原对象状态容易推导出错误结论。
不要通过修改原lastIndex来尝试控制已经创建的matchAll迭代器跳跃。若业务需要按任意位置重新开始，应创建新的匹配过程，并明确如何去重前面已经处理的命中。依赖外部共享正则去驱动一个内部状态副本，既难维护，也与这里展示的协议不符。
结果迭代器也有自己的生命周期
第一轮iterator已经被展开成数组，再次展开得到空数组。matchAll返回的是一次性迭代器，而不是可重复查询的结果集合。要多次遍历同一批匹配，可以保留第一次生成的数组；要重新扫描，则重新调用matchAll。两者在时间、内存与创建时起点上都有不同含义。
匹配对象不仅包含匹配文字，还带有索引与捕获信息。示例只取文字和index，让输出可以稳定比较。实际做高亮时，应保留真实位置，而不是对匹配文字再调用indexOf，因为相同文字可能出现多次，重新查找容易总是定位到第一处。
示例索引基于ASCII，所以每个字符对应一个UTF-16码元。换成包含代理对的字符时，JavaScript字符串索引仍按码元计数，不能直接当成用户看到的字符序号或字节偏移。这个问题与游标复制相互独立，界面高亮和二进制协议需要分别进行位置映射与测试。
g标志与可扩展协议的边界
最后一段把不带g的/a/传给字符串matchAll，立即得到TypeError。这是对传入普通RegExp的要求，不是说正则表达式在所有API中都必须全局匹配。迁移代码时，应确认调用入口和正则标志，而不是只把exec名称改成matchAll并保留原参数。
本文描述的是原生普通正则的行为。JavaScript允许对象定制Symbol.matchAll，也存在影响构造与匹配的扩展入口；这类对象可以有不同副作用。若库函数接受外部提供的任意匹配器，应收窄类型或审查协议，不能仅凭方法名断言它一定不修改外部状态。
正则的其他标志也会影响搜索含义。例如粘连匹配关注指定位置是否直接命中，而普通g允许从起点继续向后查找。本例起点一是空格，仍找到后面的a，正是普通全局搜索的结果。修改标志后应保留这个非命中起点样本，避免把搜索模式改变误归因于副本机制。
回归测试可以围绕零起点、非零起点、超出末尾、创建后修改原对象、重复消费以及缺少g六种情况展开。每组同时检查匹配索引与原lastIndex，才不会只因输出条数正确而漏掉状态污染或起点遗漏。共享正则越多的代码库，越需要把这些状态约定写在接口旁。
把正则与结果生命周期分开管理也有助于并发可读性。为每次搜索创建清晰的局部状态，或者把起点作为显式参数传入，比让多个调用者轮流修改一个全局pattern更容易复核。matchAll减少了一类游标副作用，但它并不会自动消除调用者已经引入的共享状态设计问题。
排查漏掉首个命中时，先在创建迭代器之前打印起点，再核对调用方是否复用了此前执行过test或exec的正则。只在消费结束后查看原lastIndex，无法还原创建时的全部背景。将起点、输入长度和标志放进受控调试记录，通常比只打印匹配数组更快定位原因；记录文本本身时仍需避免泄露敏感内容。
参考资料与验证记录
官方资料核验于2026年10月3日。本次完整程序退出码为0，标准错误为空；例子验证的是上述固定输入与运行环境，不表示所有平台和版本的输出细节完全一致。
