regex.match 用于判断匹配或获取首个结果，轻量安全；regex.matches 返回 matchcollection 以遍历全部匹配，但需用 foreach 或转列表访问，避免索引取值导致性能浪费。
匹配字符串时 Regex.Match 和 Regex.Matches 到底选哪个
看你要不要全部结果。只判断是否匹配、或只要第一个匹配项，用 Regex.Match；要遍历所有匹配（比如提取多个邮箱、多个数字），必须用 Regex.Matches，它返回 MatchCollection，不是数组，不能直接用索引访问——得用 foreach 或转成列表。
常见错误是写成：var m = Regex.Matches(input, pattern)[0]，看似取第一个，但内部仍执行了全量扫描，浪费性能；如果只想要第一个，Regex.Match 更轻量、也更安全（不会因空集合抛 IndexOutOfRangeException）。
注意点：
-
Regex.Match返回Match，.Success为false表示没匹配到，别直接取.Value -
Regex.Matches在 .NET 5+ 默认是惰性求值，循环中修改原字符串不会影响已缓存的匹配结果，但别在遍历时调.Count——会强制枚举全部 - 如果正则里用了
^或$，记得确认是否启用了RegexOptions.Multiline，否则它们只匹配整个字符串首尾，不匹配每行
Regex.Replace 的回调函数怎么写才不出错
当替换逻辑依赖捕获组内容、或需要运行时计算（比如把日期格式从 yyyy-MM-dd 转成 dd/MM/yyyy），就得用带 MatchEvaluator 的重载，而不是简单字符串替换。
最常踩的坑是：在回调里直接拼接 match.Groups[1].Value，却没检查 Groups[1].Success ——分组可能根本没参与匹配（尤其用了 ? 或 | 的时候），这时 .Value 是空字符串，不是 null，但语义已经错了。
实操建议：
- 回调函数签名必须是
string MatchEvaluator(Match)，别漏return - 用
match.Groups["name"].Success判断具名分组是否存在，比靠索引更稳 - 避免在回调里做耗时操作（如 IO、数据库查询），
Replace是同步阻塞的，会影响整体响应 - 如果只是简单替换，优先用
Regex.Replace(input, pattern, replacement)，其中replacement可含$1、${name}等引用语法，比写回调更高效
编译正则表达式：什么时候该用 RegexOptions.Compiled
它会让正则在首次使用时编译成 IL，后续执行更快，但代价是启动慢、内存占用高（尤其模式多的时候）。不是所有场景都适合。
适用场景很窄：正则模式固定、且单个实例被反复调用（比如 Web API 里全局复用的验证规则）；其他情况——比如每次请求都生成新 Regex 实例、或模式来自用户输入——加 Compiled 反而拖慢速度、还可能触发 JIT 编译异常。
关键事实：
- .NET Core 3.0+ 对未标记
Compiled的正则做了大量优化，多数情况下性能差距已不明显 - 若真要用，务必缓存
Regex实例（静态字段或 DI 容器注册），否则每次 new 都重新编译，白费功夫 - 在 AOT 编译环境（如 .NET 6+ 的 NativeAOT）中，
Compiled会被忽略，甚至报错，此时必须去掉
中文字符匹配为什么总漏掉或者多匹配
根本原因是没搞清 Unicode 范围。写 [一-龥] 看似覆盖汉字，其实只含基本汉字区（CJK Unified Ideographs），漏了扩展 A/B 区、标点、全角数字字母，甚至 emoji 中的汉字变体。
更可靠的方式是用 Unicode 类别：\p{Han} 匹配所有汉字（包括扩展区），\p{P} 匹配任意标点，\p{Z} 匹配空白分隔符。注意大小写敏感——\P{Han} 是“非汉字”，别手抖写反。
实际写法建议：
- 匹配纯中文字符串：
^\p{Han}+$，开头结尾加锚点，避免混入空格 - 提取中英文混合文本里的中文词：
\p{Han}+，别加g标志（C# 用RegexOptions.Global，但默认就是全局匹配） - 如果正则里同时有
\p{Han}和[a-zA-Z]，注意 .NET 默认不开启 Unicode 感知，但现代版本已默认启用；保险起见可显式加RegexOptions.CultureInvariant
事情说清了就结束。正则最难的从来不是语法，而是边界——比如“中文”到底指哪部分、“重复”要不要跨行、“空白”算不算制表符。这些得结合具体数据看，不能光背模式。
