带g标志的正则反复调用test()时lastindex持续推进，导致匹配位置偏移、结果不一致；应去掉g标志、手动重置lastindex或使用字面量新建正则来规避。

直接说结论：带 g 标志的正则表达式在反复调用 test() 时，lastIndex 会持续推进，导致后续匹配从非起始位置开始，极易漏判或结果不一致——这不是 bug，是设计行为，但常被忽略。

test() 的 lastIndex 推进机制

只要正则设置了 g（全局标志），每次 test() 成功匹配后，lastIndex 就自动更新为本次匹配结束后的下一个字符索引。下一次调用仍从该位置继续搜索，而非重头开始。

• 若字符串长度不足以支撑下一次起始位置（lastIndex > str.length），test() 返回 false，并立即将 lastIndex 重置为 0
• 若匹配失败但 lastIndex ≤ str.length，lastIndex 不变，下次仍从此处尝试
• 即使换一个完全不同的字符串测试，只要正则对象没重建，lastIndex 状态依然延续

高频调用下的典型干扰场景

表单校验、输入实时反馈、循环批量验证等场景中，若复用同一个带 g 的正则对象反复 test()，极易触发状态污染。

• 第一次 /\d{4}\/\d{2}\/\d{2}/g.test('2026/05/06') → true，lastIndex 变为 10
• 第二次 .test('2026-05-06') → 从第 10 位开始搜，字符串才 10 位长，实际已越界 → false（但本应匹配失败是因格式不对，不是因位置）
• 第三次再试原字符串，lastIndex 已是 0（因上次失败触发了重置），结果又变回 true —— 同一正则、同一输入，结果却随调用顺序浮动

规避 lastIndex 干扰的实用方案

核心原则：让每次匹配都“干净开始”。有三种可靠方式：

• 去掉 g 标志：绝大多数校验只需判断“是否存在匹配”，无需全局遍历，/\d{4}\/\d{2}\/\d{2}/.test(str) 安全稳定
• 每次调用前手动重置：在 test() 前加 regex.lastIndex = 0，适用于必须保留 g 但又不想重建正则的场合
• 改用字面量新建正则：如 if (/\d{4}\/\d{2}\/\d{2}/.test(str)) { ... }，每次都是独立实例，无状态残留

如何快速定位是否受 lastIndex 影响

调试时可直接打印关键状态：

• 在 test() 前后输出 regex.lastIndex 和 regex.global
• 对同一输入连续调用两次 test()，结果不同 → 几乎必是 lastIndex 在作祟
• 把正则换成不带 g 的版本再试，结果稳定了 → 验证结论