Go的regexp包不支持按名称取值，必须依赖捕获组顺序索引；FindStringSubmatch返回的[][]byte中result[0]为全匹配，result[1]起依次对应正则中左括号出现顺序，易因分支、嵌套或未匹配导致越界或nil，需严格检查len和nil；推荐分治处理多格式匹配并用注释明确各组语义。
regexp 包本身不提供“按名称直接取值”的方法，所有提取都依赖括号捕获组的顺序索引。想安全、稳定地提取内容，必须严格控制正则结构和匹配逻辑，否则 match[i][j] 极易越界或返回空。
为什么 FindStringSubmatch 返回的切片下标容易出错
调用 FindStringSubmatch 后得到的是 [][]byte，其中 result[0] 是完整匹配，result[1] 是第一个括号组，result[2] 是第二个……依此类推。但这个顺序完全由正则中 (...) 出现的**物理位置**决定，不是命名、也不是语义。
常见错误现象：
- 写成
(?P<year>\d{4})-(?P<month>\d{2})</month></year>，以为能用match[0]["year"]—— Go 不支持这种语法 - 正则里带可选分支，比如
(\d{4})|(\w+)，一次匹配只会填充其中一个括号，另一个是nil，result[1]和result[2]可能一真一空 - 嵌套括号没注意层级，比如
((a)(b))，result长度是 4（全匹配 + 3 个组），但开发者只按 2 个组去读，result[2]就 panic
正确做法是：先确认 len(result) > 2，再逐个检查 result[i] != nil，不能假设每个括号都有值。
提取日期字段时如何避免子表达式索引错乱
多个日期格式（如 MM/DD/YYYY、YYYY-MM-DD、Jan 1, 2023）如果硬塞进一个 | 拼接的正则，SubexpNames() 返回的名称列表会混乱，result 的长度也不固定 —— 因为不同分支的括号数量不同。
立即学习“go语言免费学习笔记（深入）”；
推荐方式是分治处理：
- 为每种格式单独写一个正则，都带相同命名意图的括号，例如
(\d{1,2})/(\d{1,2})/(\d{4})、(\d{4})-(\d{1,2})-(\d{1,2}) - 依次用
re1.FindStringSubmatch、re2.FindStringSubmatch尝试匹配，只要一个非nil就停止 - 每个正则只负责自己那套括号顺序，
result[1]永远是“月”，result[2]永远是“日”，不会串
这样虽然多几行代码，但调试时一眼能看出哪条规则生效，也避免了 index out of range。
从匹配结果中安全提取字符串值的三步检查
FindStringSubmatch 返回 [][]byte，要转成 string 还得小心空值和字节边界。实际使用必须做三层防护：
- 检查匹配是否发生：
if len(matches) == 0→ 直接跳过，不要访问matches[0] - 检查目标组是否存在：
if len(matches) > 2 && matches[1] != nil→ 才能取年份 - 转
string前确认非空：yearStr := string(matches[1])，但若matches[1]是nil，string(nil)得到空字符串，不会 panic，但业务上可能误判
别省略这些判断。线上服务里，一个未校验的 matches[2] 就足以让 goroutine crash。
命名组只是语法糖，别指望它帮你自动对齐
Go 支持 (?P<name>...)</name> 写法，但 SubexpNames() 只返回名称列表，不提供反向映射。你无法通过 "year" 查到它对应第几个括号 —— 除非你自己遍历 SubexpNames() 找索引，再拿那个索引去查 matches。这既慢又容易错。
真正省事的做法是：放弃命名组幻想，老老实实用位置索引，并在正则注释里写清楚每个括号的含义。例如：
// (\d{4}) = year, (\d{1,2}) = month, (\d{1,2}) = day
re := regexp.MustCompile(`(\d{4})-(\d{1,2})-(\d{1,2})`)
这样比任何命名都可靠。Go 的正则设计就是偏底层、偏显式的，想靠语法糖偷懒，最后反而花更多时间 debug。
