regexp.mustcompile 一用就 panic 是因传入非法正则（如未闭合括号、错误转义），它不返回 error 而是直接 panic；应先用 regexp.compile 测试并检查 err。
regexp.MustCompile 为什么一用就 panic
因为传入了非法正则表达式，比如未闭合的括号、错误的转义序列，regexp.MustCompile 会直接 panic，不返回 error。开发时别图省事，先用 regexp.Compile 测试：
- 用
regexp.Compile替代regexp.MustCompile，检查返回的err - 常见报错：
error parsing regexp: missing closing ]（方括号没闭）、error parsing regexp: invalid escape sequence（如写成d却忘了加双反斜杠） - Go 字符串字面量里写反斜杠必须双写：
\d才表示正则中的d，单写d是非法转义
FindStringSubmatch 和 FindAllString 的关键区别
前者返回匹配的「子组捕获内容」（[]string），后者只返回全部匹配项（不含括号分组）。你真正要提取邮箱用户名或 URL path 段时，大概率需要的是 FindStringSubmatch 或配套的 FindSubmatch 系列。
-
FindString：只取第一个完整匹配字符串，无分组信息 -
FindStringSubmatch：返回[]byte切片，包含整个匹配 + 所有子组（索引 0 是全匹配，1 是第一个()，依此类推） - 注意：如果正则里用了非捕获组
(?:...)，它不会出现在结果切片中 - 性能上，
Submatch系列比String系列略慢，但少一次string()转换开销；若需频繁提取子组，别自己切string，直接用Submatch
正则编译后复用，但别全局共享一个 *regexp.Regexp 实例
编译正则代价高，所以应复用 *regexp.Regexp 实例；但多个 goroutine 并发调用它的方法（如 FindString）是安全的——文档明确写了并发安全。不过仍有两个实际陷阱：
- 别把
*regexp.Regexp存在 map 里再反复delete/store，容易误删正在被其他协程使用的实例 - 如果正则依赖运行时拼接（比如带用户输入的关键词），务必对输入做白名单过滤或转义，
regexp.QuoteMeta是你的朋友 - 避免在 hot path（如 HTTP handler 内）每次调用都
Compile，哪怕加了缓存，也要注意 map 并发读写需加锁或改用sync.Map
中文、emoji、Unicode 字符匹配经常漏掉的点
Go 正则默认按 UTF-8 字节处理，不是 Unicode 字符。写 . 或 w 时，它们不匹配中文、emoji 等非 ASCII 字符，除非显式启用 Unicode 类别支持。
立即学习“go语言免费学习笔记（深入）”；
-
w默认只等价于[0-9A-Za-z_]，不包括汉字或 emoji；要用p{L}（任意字母）、p{Han}（汉字块）等 Unicode 类别 - 写
[u4e00-u9fa5]能覆盖常用汉字，但漏掉扩展 A/B 区、生僻字；稳妥做法是p{Han}+p{Common} - emoji 多为组合字符（如 ??），单个
.可能只匹配其中一部分；用p{Emoji}或更宽泛的p{So}（symbol, other） - 测试时用
len([]rune(str))看字符数，别用len(str)看字节数，否则长度判断逻辑会出错
