正则修饰符的书写位置（内联或末尾）对性能影响通常可忽略，真正影响执行效率的是全局标志 g 是否启用以及匹配次数。JavaScript 标准正则主要使用末尾标志，内联标志多见于 PCRE 等引擎，公开资料中没有看到可靠的量化数据证明两者存在显著速度差异。

命令速用版

以下代码片段展示不同标志位的标准写法，直接用于测试环境验证行为差异。

// JavaScript 标准写法（末尾标志）
const reg1 = /pattern/gi; 
const reg2 = new RegExp("pattern", "gi");

// PCRE/Python 等支持内联标志（JavaScript 通常不支持）
// const reg3 = /(?i)pattern/; // 多数 JS 引擎会报错

// 全局匹配 vs 单次匹配
const text = "a b c a b c";
console.log(text.match(/a/));    // 返回第一个匹配 ["a"]
console.log(text.match(/a/g));   // 返回所有匹配 ["a", "a"]

为什么会这样

正则引擎在编译阶段处理标志位，运行阶段主要消耗在字符匹配循环上。标志位无论是写在末尾还是内联，最终都会转化为引擎内部的状态机配置，不改变核心匹配算法的复杂度。

全局标志 g 会改变匹配行为：未启用 g 时，引擎找到第一个匹配项即停止；启用 g 后，引擎会更新 lastIndex 属性并持续搜索直到字符串末尾。因此，g 标志的性能消耗与匹配项数量成正比，而非标志位写法本身导致。

分步处理

若需验证具体场景下的性能表现，请按以下步骤操作，避免被微观基准测试误导。

1. 确认引擎支持：检查当前运行环境（如 Node.js 版本、浏览器内核）是否支持内联标志语法，JavaScript 标准环境通常仅支持末尾标志。

2. 控制变量测试：保持正则模式不变，仅切换标志位写法（如支持）或切换 g 标志，避免同时修改模式复杂度。

3. 模拟真实数据：使用与实际业务量级相当的字符串长度进行测试，短字符串的耗时差异通常无统计意义。

4. 多次运行取平均：单次测试受 JIT 编译预热影响较大，建议循环执行多次后计算平均耗时。

怎么验证是否生效

使用 console.time 或性能分析工具观察执行耗时，同时检查匹配结果是否符合预期。

console.time("regex-test");
for (let i = 0; i < 10000; i++) {
  "hello world".match(/hello/g);
}
console.timeEnd("regex-test");

// 验证 lastIndex 行为（仅针对 g 标志）
const reg = /test/g;
reg.test("test test");
console.log(reg.lastIndex); // 有 g 标志时会更新位置，无 g 标志通常为 0

常见坑

1. lastIndex 陷阱：带 g 标志的正则对象在连续调用 test 或 exec 时会保留 lastIndex 状态，可能导致第二次匹配从中间开始而漏掉结果，需手动重置 reg.lastIndex = 0。

2. 引擎兼容性：不要假设所有语言都支持内联标志，JavaScript historically 不支持(?i) 写法，强行使用会抛出 SyntaxError。

3. 过度使用全局匹配：若只需判断是否存在（如表单验证），使用 g 标志会浪费性能遍历剩余字符串，建议仅用 test 方法且不加 g。

常见问题

内联标志比末尾标志更快吗？

公开资料中没有看到可靠的量化数据支持这一结论，两者在编译后通常生成相同的内部结构。

全局标志 g 会显著降低性能吗？

取决于匹配次数，若字符串中匹配项极多，g 标志会导致引擎持续工作直到末尾，耗时自然增加。

JavaScript 支持内联标志吗？

标准 JavaScript 正则表达式通常不支持内联标志，建议在斜杠后使用 i、g、m 等末尾标志。

参考来源

• 正则表达式标志位 (Flags):i、g、m、s、u、y 的全解析
• 正则表达式中的匹配模式
• Global 属性说明文档
• 正则表达式学习笔记