go的regexp包不支持match.group("name")式访问，命名组仅为语法糖，必须通过subexpnames()获取名称索引映射，并结合findstringsubmatchindex()提取字节位置才能安全取值。
Go 的 regexp 包不支持像 Python 那样用 match.group("name") 直接按名取值——命名组只是语法糖，底层仍靠索引访问，必须手动映射名称到位置。
SubexpNames() 是命名组唯一可靠的名称索引表
SubexpNames() 返回的 []string 是你唯一能信任的“名称→索引”依据。它按子表达式左括号出现顺序排列，索引 0 恒为 ""（整匹配），后续每个元素对应一个捕获组：命名组返回其名称，未命名组返回 ""。
- 正则
(?P<year>\d{4})-(?P<month>\d{2})</month></year>→SubexpNames()返回["", "year", "month"] - 正则
(?P<id>\w+):(?P<val>.*)</val></id>→ 返回["", "id", "val"] - 若混用命名与未命名组，如
(?P<key>\w+):(.*)</key>→ 返回["", "key", ""]，第二个空字符串代表未命名组 - 切勿假设名称在切片中“连续”或“去重”——重复命名、分支
|、嵌套都会导致名称重复或错位
FindStringSubmatchIndex 是获取命名组字节位置的唯一可靠方式
想拿到某个命名组的实际起止位置（比如用于后续切片或高亮），必须用 FindStringSubmatchIndex()，它返回 [][]int，每项是 [start, end) 字节偏移对，顺序与 SubexpNames() 完全一致。
- 对匹配结果
m，m[0]是整匹配范围，m[1]对应SubexpNames()[1]，以此类推 - UTF-8 文本中需转 Unicode 位置：用
utf8.RuneCountInString(s[:start])算字符起始索引 - 若某组未匹配（如分支未命中），对应位置为
[-1, -1]，必须检查，不能直接切片 - 避免用
FindStringSubmatch()提取内容再算长度——多字节字符下字节长度 ≠ 字符数，易越界
Go 1.22+ 的 FindStringSubmatchMap 简化了常见场景，但仍有边界限制
FindStringSubmatchMap() 确实能一步返回 map[string][]byte，省去手动映射步骤，但它只适用于单次匹配、且所有命名组都实际参与匹配的情形。
- 它对
|分支正则无效：如(?P<a>\d+)|(?P<b>\w+)</b></a>，每次匹配只激活一个分支，未激活组在 map 中消失（不是nil，是根本不存在） - 不处理重复命名：若正则中两个
(?P<id>\w+)</id>，map 只保留最后一个匹配值 - 返回的是
[]byte，不是string；若需字符串，得显式转string(val) - 旧版本（
多字段提取别拼一个大正则，用循环+小正则更稳
面对类似 UUID=abc123>Make=DELL> 这种键值对结构，硬写 (?:UUID=)(?P<uuid>.*?)>|(?:Make=)(?P<make>.*?)></make></uuid> 是典型陷阱：分支导致 SubexpNames() 返回 ["", "uuid", "", "make", ""]，而每次匹配只填其中一个，其余为空，FindAllStringSubmatch 返回的每个子切片长度固定但内容稀疏。
- 正确做法是写一个精准小正则，如
`(\w+)=(\w+)>`，不命名也行，用两次FindAllStringSubmatch循环提取 - 或为每个字段单独编译正则：
reUUID := regexp.MustCompile(`UUID=(\w+)>`)，调reUUID.FindStringSubmatch单独取值 - 结构化文本（如 XML/HTML 片段）优先考虑专用解析器，正则仅作轻量预处理
- 命名组真正价值在于提升正则可读性，而非运行时便利性——别让它成为调试负担
最易被忽略的一点：Go 正则引擎不保证命名组在 SubexpNames() 中的顺序“语义连续”，只保证“括号出现顺序”。只要正则里括号嵌套、分支、非捕获组混用，名称索引就可能跳变。动手前先打印 re.SubexpNames() 看一眼，比猜强十倍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
