go regexp不支持命名捕获组直接索引，必须按括号物理顺序访问result[i]，且需严格检查len(match)>i和match[i]!=nil，否则易panic；subexpnames()仅辅助映射名称到索引，不改变索引逻辑。
Go 的 regexp 包不支持命名捕获组的直接索引访问（比如 match["year"]），所有提取必须依赖括号出现的物理顺序和严格的手动边界检查。跳过这一步，match[1] 很容易 panic 或返回 nil。
为什么 FindStringSubmatch 返回的 [][]byte 下标容易越界
调用 FindStringSubmatch 后得到的是一个二维切片：[][]byte，其中 result[0] 是完整匹配，result[1] 是正则中第一个 () 的内容，result[2] 是第二个……这个顺序完全由左括号在正则里的书写位置决定，和语义无关。
- 写成
(?P<year>\d{4})-(?P<month>\d{2})</month></year>—— Go 不识别?P语法，result[1]仍对应第一个括号，不是 “year” - 正则含分支如
(\d{4})|(\w+)：一次匹配只填充其中一个括号，另一个是nil，result[1]和result[2]可能一真一空 - 嵌套括号如
((a)(b))：实际生成 4 个子表达式（全匹配 + 3 个组），但开发者常按 2 个组读取，result[2]就越界 - 未匹配的捕获组一律返回
nil，不是空字符串；直接string(match[1])会 panic
FindStringSubmatch 提取单次匹配的括号内容（最常用场景）
这是处理结构化字符串（如 query="tag1 tag2"）的标准路径：先用非贪婪捕获拿到引号内完整内容，再用 strings.Fields 分割。
- 正则必须带
()，否则match长度恒为 1（只有全匹配） - 推荐用
[^"]*替代.*?，避免跨引号误匹配（例如query="abc" foo="def"中不会吞掉后续引号） - 必须检查
len(match) > 1，再检查match[1] != nil，才能安全转string - 对引号内多词场景，别试图用
(\w+ )*一次性捕获多个标签——Go 不支持重复捕获组展开，match[1]只返回最后一次匹配结果
re := regexp.MustCompile(`query="([^"]*)"`)<br>match := re.FindStringSubmatch([]byte(str))<br>if len(match) return // 安全退出<br>}<br>quoted := string(match[1])<br>tags := strings.Fields(quoted)
命名捕获组仅在 Go 1.19+ 有有限支持，不能替代索引逻辑
Go 1.19 引入了 SubexpNames()，但它只是辅助工具，**不改变匹配结果的索引方式**。它返回的名称列表长度恒为 re.NumSubexp() + 1，首项为空字符串（代表全匹配），后续项按括号出现顺序排列，与 FindStringSubmatch 结果一一对应。
-
re.SubexpNames()返回[]string{"", "year", "month"}，不代表你能写match["year"] - 你仍需用
index := re.SubexpIndex("year")查到它是第 1 个组，再访问match[1] - 如果正则里写了
(?P<year>\d{4})|(?P<month>\d{2})</month></year>，两个组都存在，但一次匹配只填一个，match[index]仍可能为nil - 命名本身不提升安全性，该判空、该防越界，一步都不能少
真正容易被忽略的点是：Go 正则的“确定性”来自结构简单和边界显式。任何试图靠复杂嵌套、可选分支或重复捕获组来“一正则搞定全部”的做法，最终都会在 nil 和越界上栽跟头。老实用两步法——先捕获再处理，才是稳定提取的底层逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
