regexp.Compile 返回 nil 时直接调用方法会 panic，必须先检查 error；动态正则不能用 MustCompile；匹配中文、emoji 应用 \p{Han} 或 \p{Extended_Pictographic}；FindAllStringSubmatch 返回 [][]byte。
regexp.Compile 返回 nil 时直接调用方法会 panic，必须先检查 error；动态正则不能用 regexp.MustCompile；匹配中文、emoji 要用 \p{Han} 或 \p{Extended_Pictographic}，而不是 [一-龯] 或 .；FindAllStringSubmatch 返回的是 [][]byte，不是 []byte。
regexp.Compile 为什么一用就 panic
因为没检查返回的 error，导致 re 是 nil，后续调 re.FindString 就触发空指针 panic。
常见错误现象：
- 正则里漏写右括号，比如
(\d{3}-\d{2} - 写了 Go 不支持的转义，比如
\Q、\u后面没跟合法码点 - 量词嵌套，如
a++
正确做法永远是：
re, err := regexp.Compile(`\d{3}-\d{2}-\d{4}`)
if err != nil {
log.Fatal(err) // 或 return err
}
matches := re.FindString([]byte("123-45-6789"))
regexp.MustCompile 只适合硬编码的、启动时就确定合法的 pattern；运行时拼接的（如来自 API、配置）必须用 Compile + 显式错误处理。
立即学习“go语言免费学习笔记（深入）”；
如何安全拼接用户输入到正则中
用户输入若不转义，.、*、$ 等会变成元字符，轻则匹配失控，重则引发回溯爆炸。
必须用 regexp.QuoteMeta：
keyword := "foo.bar"
escaped := regexp.QuoteMeta(keyword) // → "foo\.bar"
re := regexp.MustCompile(escaped)
highlighted := re.ReplaceAllString("this is foo.bar", "[[$0]]")
注意：
-
QuoteMeta把所有非字母数字字符都加\，只适合字面量匹配 - 如果想保留部分语义（比如允许用户用
*表示通配），就得自己解析，不能依赖QuoteMeta - 传入前确保是非空
string，否则行为未定义
匹配中文、emoji 为什么 \w 和 . 失效
Go 的 regexp 默认按字节处理，\w 等价于 [0-9A-Za-z_]，. 不匹配 UTF-8 多字节字符（如汉字、emoji）。
正确写法是显式使用 Unicode 属性类：
- 匹配任意汉字：
[\p{Han}]+ - 匹配 emoji：
\p{Extended_Pictographic} - 匹配任意 Unicode 字母（含中日韩、拉丁扩展等）：
\p{L}+ - 匹配 Unicode 数字（如 ①、¼）：
\p{Nd}+（\d只认0–9）
别写 [一-龯] —— 漏字、难维护、不兼容新 Unicode 版本；也别指望 (?u)，Go 不支持该标志。
FindAllStringSubmatch 返回空 slice 怎么办
不是没匹配上，而是你没加捕获组（括号），或者误把返回值当成了 []byte。
FindAllStringSubmatch 要求正则里有 () 才返回子匹配内容；它返回的是 [][]byte，第一维是每个匹配项，第二维是该匹配的各组（索引 0 是全匹配，1 是第一个 ()）。
例如：
re := regexp.MustCompile(`https?://([^/]+)`)
matches := re.FindAllStringSubmatch([]byte("https://golang.org/pkg"), -1)
// matches 是 [][]byte；len(matches) > 0 时，matches[0][1] 才是域名
常见错误：
- 正则没括号，却期望
matches[0][1]存在 → 越界 panic - 用
FindAllString替代 → 完全丢弃子组信息 - 对
[][]byte直接string()转换 → 得到乱码或截断
要精准提取，优先用 FindAllStringSubmatchIndex 获取字节位置再切片，或升级到 Go 1.22+ 用 FindStringSubmatchMap（支持命名组）。
\p{Han}）在 Go 中是开箱即用的，但很多人仍习惯抄旧教程里的 [一-龯]；还有就是 FindAllStringSubmatch 的二维结构，几乎每次都会有人在循环里错当成一维切片处理。 
