go regexp匹配失败不报错，需检查返回值：findstring()返回空字符串难区分失败与空匹配，应优先用matchstring()判断再提取；中文邮箱手机号等混排文本宜分阶段定位；密码校验宜拆分为多个独立正则；日志解析推荐位置捕获组以减少内存开销。
Go regexp 匹配失败却没报错？检查 FindString 和 FindStringSubmatch 的返回值空值逻辑
Go 的 regexp 不会 panic，但匹配失败时多数方法返回空字符串或 nil 切片——这容易被当成“成功但没内容”，实际是根本没匹配上。
-
FindString()失败返回空字符串""，和匹配到空串无法区分；改用FindStringSubmatch()+ 非空判断更可靠 - 想确认是否命中，优先用
MatchString()做前置判断，再调具体提取方法 - 注意
FindAllString()返回[]string，若无匹配结果是空切片[]，不是nil；用len()判空比== nil安全
中文、邮箱、手机号混排文本里精准提取字段？别用单一大正则，分阶段 + FindStringSubmatchIndex 定位更稳
一长段含姓名、邮箱、电话的自由文本（比如客服工单），用一个正则硬套所有字段，极易因顺序/空格/标点微小差异漏匹配。真实场景建议先定位再切片。
- 用
FindStringSubmatchIndex()获取各字段起止字节位置，避免字符串切片越界（尤其含中文时） - 邮箱用
`[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}`，但注意 Go 默认不支持 Unicode 字母，要加(?i)且邮箱用户名部分需显式允许中文可选：`[\p{Han}\w._%+-]+`（需启用regexp.Ungrouped或改用regexp2） - 手机号推荐分国家区号写法，国内用
`1[3-9]\d{9}`，别写^1[3-9]\d{9}$—— 行首行尾锚点在非整行匹配时会失效
校验用户输入是否符合密码强度？Compile 后复用 *Regexp 实例，别每次 MustCompile
密码规则常含“至少1个大写+1个小写+1数字+1符号”，用多个 MatchString() 比单个复杂正则更易读、易调试，也避免回溯爆炸。
- 把每个规则编译成独立
*regexp.Regexp，全局变量或 init 函数里regexp.MustCompile一次，反复调用MatchString() - 符号集合别写死，用
[[:punct:]]（POSIX 类）比手列[!@#$%^&*]兼容性好，且能覆盖中文符号 - 长度校验交给
len(str) >= 8，别塞进正则——正则做长度检查（如{8,}）在极端输入下可能触发线性回溯，影响响应时间
从日志行提取时间戳和错误码？小心 SubexpNames 和命名捕获组的内存开销
像 "2024-05-22T14:23:01Z ERR [code=500] timeout" 这类结构化日志，用命名捕获组看着清爽，但 Go 的 SubexpNames() 返回的是完整名称列表，索引映射需手动维护。
立即学习“go语言免费学习笔记（深入）”；
- 优先用位置捕获组：
regexp.MustCompile(`(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z) (\w+) \[code=(\d+)\]`)，再按submatch[1], submatch[2], submatch[3]取值 - 若坚持用命名组（如
(?P<time>\d{4}-...)</time>），必须调用re.SubexpNames()并遍历找索引，不能假设顺序；且每次FindStringSubmatch返回的切片长度固定，含未匹配组的nil元素 - 高频日志解析场景下，命名组比位置组多约 15% 内存分配，压测时留意 GC 压力
正则写得越“聪明”，越容易在边界 case 上栽跟头；宁可多调两次 MatchString，也别堆一个带 5 层嵌套的 (?:...|...)*?。
