matchAll在处理大文本时表现稳健，关键在于可控、可预测、不崩溃；它返回迭代器而非数组，按需生成匹配项，内存占用低，状态隔离且支持中断与分页。
内存占用低，适合流式处理
返回的是迭代器，不是数组。每次调用 next() 才计算下一个匹配，不会把成千上万个匹配结果全塞进内存。比如解析几 MB 的日志文件：
- 用
match()加g会生成巨大数组，可能触发内存警告 - 用
matchAll()配合for...of或take(100)类逻辑，可边读边处理，随时中断
匹配过程稳定，不因 lastIndex 失效而漏数据
传统 exec 循环依赖正则实例的 lastIndex，一旦被其他代码修改或重用同一正则，就容易跳过匹配、重复匹配甚至死循环。
-
matchAll每次匹配都从头开始扫描，状态隔离 - 同一个正则对象多次调用
matchAll，互不影响 - 特别适合多线程模拟场景（如 Web Worker 中并行处理不同段落）
支持中断与分页，便于大数据分块处理
你可以轻松实现“只取前 N 条”或“跳过前 M 条再取”，无需预加载全部：
Array.from(str.matchAll(regex), (_, i) => i- 更高效的做法是手动遍历迭代器，计数达标即
break - 结合
TextEncoder分块读取文件时，每块调用一次matchAll，无状态残留
注意实际瓶颈不在 matchAll 本身
真正影响大文本性能的是正则表达式写法：
立即学习“Java免费学习笔记（深入）”；
- 避免贪婪回溯（如
.*在长行中反复试探） - 长词截断类正则（如
(?=\S).{0,79}\S(?!\S)|\S{80}）在超长单词上仍会线性扫描，但这是算法问题，不是matchAll的缺陷 - 若需极致速度，可先用
indexOf快速定位大致区域，再对子串用matchAll
