测试.NET Framework 4.8正则性能：是否默认缓存正则表达式？

关于「首个执行用例性能始终最差」的现象解释 #

你的判断是准确的，.NET Framework 确实默认内置正则表达式缓存机制：

• 缓存以「正则表达式模式字符串 + 匹配选项组合」作为键，存储解析完成的正则内部执行结构，默认缓存容量为15条。
• 无论你是手动通过new Regex()创建实例，还是直接调用Regex.IsMatch()/Regex.Match()这类静态方法，只要传入的模式和选项命中缓存，就会直接复用已解析完成的结构，不需要重复做正则语法校验、解析树生成、执行逻辑构建这些一次性初始化工作。

你测试中三个用例使用的正则模式完全一致，仅第三个用例多了RegexOptions.Compiled选项，因此第一个执行的用例必然会承担该模式的首次初始化开销（和你观测到的40-70ms数据吻合），后续两个用例直接命中缓存，自然耗时会降到1ms级别，和你调整执行顺序后的观测结果完全匹配。
额外说明：你测到的首个用例高耗时里，还混了一部分.NET JIT首次编译正则相关代码的开销，这部分是.NET程序冷启动的正常现象，和正则本身的执行性能无关。

日常开发是否不需要复用Regex实例、不需要开启Compiled选项？ #

这个结论不能一概而论，要结合具体使用场景判断：

不需要特殊优化的场景 #

如果你的正则满足以下特征，完全可以直接创建实例或者调用静态方法，不需要特意复用、也不需要开启编译选项：

• 正则在整个应用生命周期内调用频率极低，总调用次数不超过上千次
• 使用的都是固定、总数不超过10个的正则模式，不会触发默认缓存的淘汰机制
  这种场景下开RegexOptions.Compiled反而会拖慢速度：编译选项会在初始化时把正则生成为独立IL代码，首次初始化开销是普通解析的3-5倍，调用次数不够多的话，这个成本根本无法通过执行效率的提升摊薄。

必须做针对性优化的场景 #

碰到以下情况时，不能完全依赖默认缓存：

• 正则是高频调用的核心逻辑（比如批量数据校验、百万级文本解析、网关请求参数过滤等，单正则生命周期调用次数超过10万次）：这种场景下建议把对应Regex实例声明为静态只读字段复用，同时开启RegexOptions.Compiled，编译后的正则执行效率比默认解释执行高30%以上，足够多的调用次数完全可以覆盖首次编译的开销。
• 应用中使用的不同正则模式总数超过15个：默认缓存容量只有15，超出后最早缓存的条目会被淘汰，后续再调用时会重复触发解析开销，这类高频使用的正则建议手动做静态实例复用，不要依赖默认缓存。
• 使用动态拼接生成的正则模式：这类模式如果频繁生成会快速占满缓存，甚至造成不必要的内存占用，这类场景要么对动态规则做归一化处理，要么对高频规则提前缓存实例。

测试方法补充提醒 #

你当前的测试没有做预热环节，把JIT编译、类型加载、正则首次解析的一次性开销全算在了第一个执行的用例上，测试结果会有明显偏差。如果要拿到准确的稳定性能数据，建议在正式计时前先跑一遍所有测试逻辑完成预热，再执行计时统计；如果要验证RegexOptions.Compiled的实际收益，建议把循环次数开到100万以上，不然执行时长太短，性能差异会被系统线程调度、GC抖动等噪声完全覆盖。

内容的提问来源于stack exchange，提问作者daxu