必须将 regexp.mustcompile 提为包级变量，因其每次调用都会重复执行语法解析、nfa 构建和合法性校验等 cpu 密集操作，导致性能下降3–5倍、cpu 占比超70%，且函数内使用可能引发竞态或延迟 panic；硬编码正则用 mustcompile，动态正则必须用 compile 并显式处理 error。
别在函数里写 regexp.MustCompile，它不是“方便的快捷方式”，而是包级初始化工具——用错地方，性能和稳定性都会出问题。
为什么 regexp.MustCompile 在函数里调用等于自找麻烦
每次执行 regexp.MustCompile 都会完整走一遍语法解析、NFA 构建、合法性校验流程，纯 CPU 密集操作。压测时 regexp.(*Regexp).Compile 占 CPU 70%+，八成是这个原因。
- Go 不保证函数内
var re = regexp.MustCompile(...)的初始化顺序，可能引发竞态或延迟 panic - 哪怕只调一次（比如在 HTTP handler 里），也触发重编译——而你本可以复用一个已编译对象
- IDE 报红常因转义错误（如写成
"\d"而非`d`），但真正要命的是运行时反复编译
regexp.MustCompile 和 regexp.Compile 怎么选
核心就一条：pattern 是硬编码且启动即确定 → 用 MustCompile；pattern 含变量拼接或来自用户输入 → 必须用 Compile + 显式 err 检查。
-
MustCompile的 panic 会在程序启动时暴露，适合配置类正则（邮箱、手机号、时间格式） -
Compile返回error，漏判会导致后续nil指针调用（如re.FindString(nil)）直接 panic - 动态 pattern（如
"^" + domain + "$"）绝不能裸用MustCompile，否则非法输入会让整个服务崩掉
高频匹配下怎么避免内存和 CPU 双爆
多数业务只需要判断是否存在、或提取第一个捕获组，但很多人习惯性用 FindAllStringSubmatch，结果堆分配翻倍、GC 压力陡增。
- 只判断存在？用
re.MatchString(s)，比len(re.FindStringSubmatch([]byte(s))) > 0快 40%+ - 要提取首个子串？用
re.FindStringSubmatch([]byte(s))，返回[]byte，零分配；别用FindAllStringSubmatch再取[0] - pattern 里没括号（
()），FindStringSubmatch一定返回nil——这是常见静默失败点 - 长文本中慎用
.*，尤其后面跟可选结构（如.*?或嵌套标签），改用否定字符类（[^）或 <code>strings.Split
动态 pattern 缓存必须设上限
用户输入或 API 参数拼出的正则不能预编译，但重复 Compile 会让火焰图里 regexp.Compile 占满 CPU。缓存不是可选项，是刚需。
- 用
sync.Map[string]*regexp.Regexp缓存，key 是完整 pattern 字符串 - 每次
regexp.Compile后必须检查err——MustCompile在这里等于埋 panic - 缓存 size 必须限制（比如最多 1000 个），否则 OOM；旧版本可用
time.Now()做简易 LRU 清理 - Go 1.22+ 推荐用
sync.Map.LoadOrStore，避免并发重复编译竞争
真正卡住服务的，往往不是正则写得不够高级，而是编译时机错、匹配方式重、一个没加的 () 让 FindStringSubmatch 返回 nil 还以为逻辑没问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
