Regex.Match 返回空结果不报错是因为匹配失败本身不抛异常，仅返回 Success==false 的 Match 对象；需检查输入内容、RegexOptions 选项、转义写法及 Match/Matches 区别。

为什么 Regex.Match 返回空结果却没报错

这是最常见的困惑：正则写对了，Regex.Match 却返回 Match.Success == false。根本原因不是语法错误，而是匹配失败本身不抛异常——它只安静地返回一个失败的 Match 对象。

排查要点：

• 确认输入字符串真实存在目标模式（比如用 Console.WriteLine(input) 看原始值，避免不可见字符干扰）
• 检查是否遗漏了 RegexOptions 选项：中文或换行符常需 RegexOptions.Multiline 或 RegexOptions.Singleline
• 验证转义：C# 字符串中反斜杠要双写，"\\d+" 才等价于正则里的 \d+；用逐字字符串更安全：@"\d+"
• 别混淆 Match() 和 Matches()：前者只找第一个，后者返回所有匹配项的集合

Regex.Replace 中怎么保留捕获组内容

想把 "abc123def" 替换成 "abc[123]def"，但直接写 Regex.Replace(s, @"(\d+)", "[123]") 显然不行——得引用捕获内容。

正确做法是用 $1、$2 引用分组：

string input = "abc123def";
string result = Regex.Replace(input, @"(\d+)", "[$1]");
// result == "abc[123]def"

注意：

• $0 表示整个匹配项，$1 是第一个捕获组（括号内），不能写成 \1（那是 Regex.Replace 的旧式写法，已不推荐）
• 如果用了命名组，如 "(?\\d+)"，就用 ${num}
• 替换字符串里有字面量 $ 时，必须写成 $$，否则会被误认为分组引用

用 RegexOptions.Compiled 一定更快吗

不是。它只在**同一正则反复使用上百次以上**时才值得开启。编译会显著增加首次调用开销，并占用更多内存。

适用场景判断：

• 静态正则（如校验邮箱、手机号）且高频调用 → 可用 static readonly Regex + Compiled
• 动态生成的正则（如用户输入的搜索模式）→ 绝对不要 Compiled，避免内存泄漏和 JIT 压力
• 一次性使用的正则（如解析某段临时日志）→ 默认选项即可，省去编译成本

典型安全写法：

private static readonly Regex EmailRegex = 
    new Regex(@"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$", 
               RegexOptions.Compiled | RegexOptions.IgnoreCase);

为什么 Regex.IsMatch 在某些字符串上特别慢

常见于含大量重复结构又带回溯的模式，例如 "a+b*" 配对 "aaaaaaaaaa..."，可能触发指数级回溯（ReDoS）。

规避方式：

• 避免嵌套量词："(a+)+" 比 "a+" 危险得多
• 用原子组或占有性量词（C# 从 .NET 5+ 支持 ++、*+）切断回溯："a++b"
• 对用户可控的正则做超时防护：Regex.Match(input, pattern, RegexOptions.None, TimeSpan.FromMilliseconds(100))
• 优先考虑非正则方案：URL 解析用 Uri.TryCreate，JSON 用 System.Text.Json，比手写正则稳得多

正则不是万能胶，尤其当模式变复杂、输入不可控时，边界条件和性能退化往往来得突然。