Regex 在高并发场景下为什么会变慢？
因为默认的
Regex实例不是线程安全的，且每次调用
new Regex(pattern)或静态方法如
Regex.IsMatch(input, pattern)时，.NET 会隐式缓存编译结果——但这个缓存是弱引用 + LRU 策略，高并发下容易失效或频繁重编译。更关键的是，缓存键只包含
pattern和
RegexOptions，不区分调用上下文，多个线程争抢同一缓存项会触发内部锁（
RegexCache.s_lock），成为瓶颈。 现象：QPS 上千后，
Regex.IsMatch的 CPU 占用陡增，profiler 显示大量时间花在
RegexRunner.Scan和锁等待上 根本原因不是正则本身慢，而是编译开销和缓存同步开销被放大 尤其当 pattern 来自配置或用户输入（无法提前预编译）、且 options 动态变化时，缓存命中率趋近于 0
Regex.CompileToAssembly 已被废弃，别再用了
Regex.CompileToAssembly是 .NET Framework 2.0–4.x 提供的“把正则编译成独立 DLL”的方案，目的是绕过运行时编译。但它在 .NET Core/.NET 5+ 中**完全移除**，官方文档明确标记为 obsolete，且存在严重缺陷： 生成的程序集无法跨平台（依赖
System.Text.RegularExpressions的具体实现细节） 每次 pattern 或 options 变更都要重新生成、部署新 DLL，运维成本爆炸 生成的类型必须 public，破坏封装；且需反射加载，丢失编译期类型检查 实际性能提升有限——现代 JIT 和 Regex 源生编译（
RegexGenerator）已远超它
如果你在旧项目里还看到
Regex.CompileToAssembly调用，第一件事是搜索替换为
RegexOptions.Compiled或（更推荐）
RegexGenerator。
替代方案：用 RegexGenerator（.NET 7+ 推荐）或预编译实例
.NET 7 引入源码生成器
RegexGenerator，在编译期把正则转为纯 C# 代码，零运行时编译、零反射、无锁——这才是高并发下的正解。
[RegexGenerator(@"\d{3}-\d{2}-\d{4}", RegexOptions.None)]
public static partial class SsnRegex
{
public static partial bool IsMatch(ReadOnlySpan<char> input);
}使用时直接调用
SsnRegex.IsMatch(input)，性能接近手写字符串扫描。注意： 必须用
partial类 +
static方法，且 generator 属性参数必须是编译期常量 不支持运行时拼接的 pattern（比如
string.Format("{0}.*", userPattern)）
若还在用 .NET 6 或更早，退而求其次：把常用 pattern 提前构造为静态 Regex实例，并显式指定
RegexOptions.Compiled
例如：
private static readonly Regex EmailRegex = new Regex(@"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$", RegexOptions.Compiled | RegexOptions.NonBacktracking);⚠️ 注意：
RegexOptions.Compiled在 .NET 5+ 中已默认启用 JIT 编译，加不加影响不大；真正有用的是
RegexOptions.NonBacktracking（防止回溯爆炸）和确保实例复用。
动态 pattern 场景下怎么保性能？
当 pattern 必须来自数据库、API 或用户输入时，无法用
RegexGenerator，也不能每次 new —— 此时核心策略是「控制编译频次 + 隔离缓存」： 用
ConcurrentDictionary<string regex></string>手动缓存，key 为
pattern + options.GetHashCode()拼接字符串 限制缓存大小（如最多 100 个），避免内存泄漏；用
Lazy<regex></regex>防止并发重复编译 对高频 pattern（如日志行解析），可预热：应用启动时主动编译并注入缓存 绝对不要在循环里写
new Regex(pattern)，哪怕 pattern 看似固定——JIT 不会帮你优化掉
一个最小可行缓存示例：
private static readonly ConcurrentDictionary<string, Lazy<Regex>> _regexCache = new();
public static Regex GetOrCompile(string pattern, RegexOptions options = RegexOptions.None)
{
var key = $"{pattern}_{options.GetHashCode()}";
return _regexCache.GetOrAdd(key, _ => new Lazy<Regex>(() => new Regex(pattern, options))).Value;
}真正难的不是写对这十几行，而是意识到：正则不是“写完就扔”的胶水代码，高并发下它和数据库连接、内存分配一样，是需要显式治理的资源。
