Regex高并发变慢主因是缓存争用与频繁重编译：弱引用LRU缓存+共享锁导致锁竞争，pattern动态时命中率趋零；应改用RegexGenerator（.NET7+）或静态预编译实例。
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>手动缓存，key 为pattern + options.GetHashCode()拼接字符串 - 限制缓存大小（如最多 100 个），避免内存泄漏；用
Lazy<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;
}真正难的不是写对这十几行，而是意识到：正则不是“写完就扔”的胶水代码，高并发下它和数据库连接、内存分配一样，是需要显式治理的资源。
