regex.match只匹配第一个是因为其设计为单次匹配；需用regex.matches获取全部结果，注意^/$在多行文本中需加regexoptions.multiline。
Regex.Match 为什么只匹配第一个就停了
因为 Regex.Match 的设计就是单次匹配——它只找从开头起第一个能匹配成功的子串，不遍历全文。你想要全部匹配结果，得用 Regex.Matches。
- 常见错误现象：
Regex.Match返回的Match.Success是 true，但Match.NextMatch()又返回空匹配，误以为漏了内容 - 正确做法：直接用
Regex.Matches得到MatchCollection，再 foreach 遍历每个Match - 注意：如果正则里用了
^或$，默认是按整行锚定；多行文本需加RegexOptions.Multiline才能让^匹配每行开头 - 性能影响：对超长文本反复调用
Match.NextMatch()比一次性Matches稍慢，且容易写错循环终止条件
Replace 时怎么保留部分原始内容（比如提取括号里的东西）
靠捕获组 + 替换模式字符串实现，不是靠变量拼接。关键在 、 这类占位符，它们对应正则中第几个 () 捕获组。
- 常见错误现象：写成
"prefix" + match.Groups[1].Value + "suffix"手动拼，结果漏掉非匹配段、逻辑臃肿、无法处理重叠或嵌套场景 - 正确写法：
Regex.Replace(input, @"(\d+)-(\w+)", "ID:$1-Code:$2")，其中$1和$2会自动代入捕获内容 - 注意：如果正则用了命名组，比如
(?<num>\d+)</num>，替换时用${num}，别漏掉花括号 - 兼容性：.NET 5+ 支持
${name:format}做简单格式化（如${num:000}），旧版本不支持
为什么 RegexOptions.Compiled 不一定更快
编译后的正则对象确实在多次调用时减少解析开销，但首次构造成本高，而且会阻止 JIT 优化某些内联路径，实际收益要看使用频次和模式复杂度。
- 常见错误现象：所有正则都无脑加
RegexOptions.Compiled，结果启动变慢、内存占用升高，单次使用的反而更慢 - 适用场景：该正则在应用生命周期内被调用数百次以上，且模式固定（不拼接字符串生成）
- 参数差异：静态缓存的
Regex实例（如private static readonly Regex = new(...)）比每次 new 更值得编译；临时用的Regex.Match("...", "...")形式根本不会走编译路径 - 性能提示：.NET 6+ 对短小正则做了自动内联优化，
Compiled的优势进一步收窄，优先测速再决定
中文、emoji 或特殊符号匹配总失败
多数时候不是正则写错了，而是没考虑 Unicode 字符边界和字符类含义。默认的 \w、\b、. 在 .NET 中只认 ASCII，遇到中文或 emoji 就断档。
- 常见错误现象：
\w+匹配不了“测试123”，.在RegexOptions.Singleline下仍跨不过 emoji（因为 emoji 是 surrogate pair） - 解决方法：用
\p{L}匹配任意 Unicode 字母（含中文、日文等），\p{N}匹配数字，\p{L}+才真正覆盖“测试”这类词 - 注意：
\b对中文无效，要用(? 这类零宽断言模拟“词首” - 额外提醒：如果输入含 emoji，确保字符串本身没被截断（比如从数据库读取时字段类型是
nvarchar而非varchar）
