命名分组不是语法糖，而是避免索引硬编码的关键；Groups["name"]比Groups[1]更可靠，因括号顺序变化不影响命名引用，且RegexOptions.ExplicitCapture仅禁用未命名捕获、不干扰命名分组。
命名分组不是语法糖，是避免靠索引硬编码的关键——别再用 Groups[1] 猜位置了。
为什么 Groups["name"] 比 Groups[1] 更可靠
正则表达式里加个括号就生成一个捕获组，但顺序一变、中间加个非捕获组 (?:...)，所有 Groups[i] 的下标就全乱。命名分组把逻辑和名字绑死，和括号位置完全解耦。
常见错误现象：Regex.Match(input, @"(d+)-(w+)").Groups[2].Value 在后续改成 (d+)-(?:extra)-(w+) 后直接取错值，而 Groups["suffix"] 不受影响。
使用场景：解析日志行、提取 URL 路径段、处理带固定字段名的半结构化文本（如 "id=123&name=abc"）。
实操建议：
- 用
(?<name>...)</name>语法定义命名分组，name必须是合法标识符（不能以数字开头，不能含连字符等） - 匹配后优先用
match.Groups["name"].Success判断是否存在，再取.Value，避免空引用 - 命名尽量语义化，比如用
year而不是g1，后期维护者一眼看懂意图
RegexOptions.ExplicitCapture 对命名分组的影响
这个选项会让所有未命名的括号变成非捕获组，但**不影响命名分组**——它只“显式要求你必须命名才捕获”，防止意外产生冗余组。
性能影响：少量提升（减少 GroupCollection 内存分配），但主要价值是强制规范。没开它时，(d+)(w+) 会产生 3 个组（0 是全匹配，1 和 2 是捕获）；开了之后，只有 0 号组，除非你写成 (?<num>d+)(?<word>w+)</word></num> 才有 1、2 号命名组。
实操建议：
- 新项目建议默认加
RegexOptions.ExplicitCapture，配合命名分组，让意图清晰 - 调试时如果发现
match.Groups.Count == 1却预期有多个，先检查是否误启用了该选项且忘了命名 - 不要为了省事在开启此选项后写
(?<>d+)——空名非法，会抛ArgumentException
命名分组嵌套和重复名的处理边界
C# 的 Regex 不支持同名分组多次捕获（即不支持 (?<tag><[^>]+>)+ 中所有 tag 都保留），它只保留最后一次匹配的值。需要全部捕获得用 Match.Captures["tag"]，但注意这是 CaptureCollection，不是 Group。
嵌套命名组完全合法：(?<outer>(?<inner>d+):(?<inner>w+))</inner></inner></outer>，但内层同名会覆盖——最终 match.Groups["inner"].Value 是第二个括号的内容。
实操建议：
- 需要多次匹配同一模式（如解析 CSV 多列），别依赖重复命名，改用循环
Match.NextMatch()或Regex.Matches() - 嵌套时若需区分，给不同层级起不同名，比如
date_year和time_hour，别图省事都叫part -
Captures是只读集合，不能用.Add()，别被 IntelliSense 误导
最易忽略的一点：命名分组名在 Regex 构造时就被编译进正则引擎，运行时无法动态拼接名字——别试图用 $"(?\d+)" 然后传给 new Regex(...)，这会导致语法错误或运行时异常；真要动态，得用字符串插值后重新编译，但代价高，应提前规划好命名结构。
