regexp.MustCompile 是最常用入口，因其在程序启动时即可暴露正则语法错误，避免运行时 panic；而 regexp.Compile 需手动检查 error，适用于用户输入等动态场景。
为什么 regexp.MustCompile 是最常用入口，而不是 regexp.Compile
因为绝大多数正则表达式在程序启动时就固定了，用 regexp.MustCompile 能提前暴露语法错误，避免运行时 panic；而 regexp.Compile 返回 error，需要手动检查，适合正则来自用户输入等动态场景。
常见错误现象：用 regexp.Compile 忘记检查 error，结果 nil 指针调用 FindString 导致 panic。
- 静态正则（如校验邮箱、提取日志时间）——直接用
regexp.MustCompile，写死在包变量里 - 动态正则（如 API 接收用户传的 pattern）——必须用
regexp.Compile+if err != nil处理 -
MustCompile的 panic 信息不带原始字符串，调试时建议先本地跑Compile看具体哪错
匹配中文、emoji 或 Unicode 字符时，\w 为什么失效
\w 在 Go 的 regexp 包里默认只匹配 ASCII 字母数字下划线（即 [a-zA-Z0-9_]），不包含中文、日文、emoji 等 Unicode 字符。这不是 bug，是设计选择 —— Go 正则引擎不支持 \p{Han} 这类 Unicode 属性类。
使用场景：想匹配“中文+英文+数字”的用户名，或提取带 emoji 的日志行。
立即学习“go语言免费学习笔记（深入）”；
- 用
[\p{Han}\p{Latin}\p{Nd}_]❌ 不生效 —— Goregexp不支持\p{...} - 改用
[\u4e00-\u9fa5a-zA-Z0-9_]✅ 显式列出常用中文 Unicode 范围 - 匹配 emoji：需覆盖
\u1f300-\u1f6ff、\u1f900-\u1f9ff等多段，建议封装成常量字符串复用 - 性能影响：Unicode 范围越宽，回溯可能性越高，长文本匹配明显变慢
FindStringSubmatch 和 FindAllStringSubmatch 返回值容易混淆
这两个函数返回的是 [][]string（注意是二维切片），不是 []string。第一维是匹配项，第二维是该匹配内各子组（括号捕获）的结果，哪怕没写括号，第 0 个元素也是整个匹配串。
常见错误现象：把 FindAllStringSubmatch 结果直接 range 出 string，编译报错或取值为空。
- 要取所有完整匹配：遍历后取每个
subs[0]，例如for _, subs := range matches { fmt.Println(string(subs[0])) } - 要取第一个捕获组：确保正则有括号，然后取
subs[1]（subs[0]是全匹配，subs[1]是第一个()） - 如果正则没括号但用了
FindStringSubmatch，返回的[][]string只有一项，且len(subs) == 1 - 别用
FindAllString替代 —— 它丢弃所有子组信息，只留主匹配
替换字符串里怎么安全引用捕获组，比如把 "user:123" 改成 "id=123"
Go 的 ReplaceAllString 不支持 $1 语法，必须用 ReplaceAllStringFunc 配合 FindStringSubmatch 手动拼接，或者更简单：用 ReplaceAllStringSubmatchFunc + 匿名函数。
最容易被忽略的点：正则里用了非贪婪 .*?，但在替换函数里没做边界控制，导致跨行或意外截断。
- 推荐写法：
re.ReplaceAllStringSubmatchFunc(s, func(m string) string { return "id=" + re.FindStringSubmatch([]byte(m))[0][1:] })—— 先匹配再提取，逻辑清晰 - 更稳的方式：用
ReplaceAllFunc（Go 1.20+）配合FindStringSubmatchIndex获取字节位置，避免 string/[]byte 转换开销 - 如果替换模板固定，预编译正则时就用
(?i)开关控制大小写，别在替换函数里反复strings.ToLower - 注意：所有
Submatch系列函数操作的是[]byte，传入 string 会隐式转，大文本频繁调用可能触发 GC
复杂点在于子组嵌套和命名捕获 —— Go 原生 regexp 不支持命名捕获，只能靠索引硬记，正则越长越容易错位。
