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是第一个捕获组（括号内），不能写成（那是Regex.Replace的旧式写法，已不推荐） - 如果用了命名组，如
"(?<num>\d+)"</num>，就用${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，比手写正则稳得多
正则不是万能胶，尤其当模式变复杂、输入不可控时，边界条件和性能退化往往来得突然。
