Regex.Match只返回第一个匹配，因其设计目标是单次查找首个成功匹配；要获取全部匹配需改用Regex.Matches方法。
Regex.Match 为什么只返回第一个匹配？
因为 Regex.Match 的设计目标就是找「首个成功匹配」，不是遍历全部。它返回 Match 对象，内部 Success 属性为 false 表示没找到，别误判为异常。
常见错误是写完 Match m = Regex.Match(input, pattern) 就直接用 m.Groups[1].Value，结果抛 IndexOutOfRangeException——其实 m.Success 是 false，但被忽略了。
- 必须先检查
m.Success，再访问Groups或Captures - 要拿全部匹配，请改用
Regex.Matches，它返回MatchCollection -
Regex.Match在性能敏感的单次查找场景下更轻量，比如验证邮箱格式是否合法
Group 和 Capture 的区别到底在哪？
简单说：Group 是「命名或编号的括号子表达式」，Capture 是「该 Group 实际匹配到的每一次内容」。一个 Group 可能有多个 Capture（比如用了 * 或 + 且开启 RegexOptions.ExplicitCapture 以外的模式）。
典型陷阱：正则 (\d+)+ 匹配 "12345"，m.Groups[1].Value 返回 "12345"（最后一次捕获），但 m.Groups[1].Captures 里其实只有一个 Capture；而 ((\d)+) 中内层 (\d) 在 "123" 下会产生 3 个 Capture。
- 需要所有重复匹配片段时，遍历
group.Captures，而不是只读group.Value - 命名组推荐用
(?<name>\w+)</name>，访问时用m.Groups["name"].Value，比硬记索引更安全 -
RegexOptions.Compiled不影响Capture行为，但会显著提升多次调用时的性能
Replace 时怎么保留部分匹配内容？
靠 $1、${name} 这类替换码，不是字符串拼接。直接写 "abc" + m.Groups[1].Value 会丢掉原始位置上下文，且无法处理多匹配。
例如把 HTML 标签转小写：Regex.Replace(html, @"]*)>", "") 是错的——${2.ToLower()} 不会被执行，只是字面量。正确做法是用 MatchEvaluator 委托：
Regex.Replace(html, @"<(/?)(\w+)([^>]*)>", m =>
$"<{m.Groups[1].Value}{m.Groups[2].Value.ToLower()}{m.Groups[3].Value}>");
-
$1只能用于简单文本替换，不能调用方法或条件逻辑 -
MatchEvaluator是唯一能动态计算替换内容的方式，适合格式转换、脱敏、上下文感知替换 - 注意委托中不要做耗时操作，否则拖慢整个
Replace过程
为什么 RegexOptions.IgnoreCase 不影响 \p{L} 这类 Unicode 类？
因为 \p{L} 匹配所有 Unicode 字母（含中文、西里尔文等），它本身不区分大小写；而 IgnoreCase 只影响 ASCII 字符的大小写映射（如 a↔A），对汉字、emoji、希腊字母无效。
真正需要“Unicode 感知”的大小写处理，得靠 TextInfo.ToTitleCase 或 string.ToUpperInvariant() 等 API，正则引擎不负责这个。
-
IgnoreCase对[a-z]有效，但对[a-я]（西里尔字母范围）不一定可靠，建议改用\p{Ll}（小写字母）和\p{Lu}（大写字母） - 匹配中文数字用
[\u4e00-\u9fff]比\p{Han}更稳妥，后者在 .NET Framework 中支持不完整 - 跨平台部署时，优先用
RegexOptions.CultureInvariant避免区域设置影响字符类行为
Match 结果看 Captures.Count 和 Success 状态。 
