不能在 handler 里反复调用 regexp.mustcompile，因为每次调用都会重复解析正则、构建状态机，导致吞吐量下降3–5倍，且运行时 panic 不带原始 pattern，难以定位问题。
为什么不能在 handler 里反复调用 regexp.MustCompile
因为每次调用都会重新解析正则语法、构建状态机，开销远大于匹配本身——实测相同 pattern 下，regexp.MustCompile 在热路径中每秒吞吐量下降 3–5 倍。更危险的是：它会在运行时 panic，且错误信息不带原始 pattern 字符串，线上出问题后根本无法快速定位是哪条正则写错了。
- panic 错误形如
panic: regexp: Compile("d+"): error parsing regexp: invalid escape sequence，但你不知道这个"d+"是从哪来的 - Go 不允许在 map 或 struct 字面量中直接调用
regexp.MustCompile，比如map[string]*regexp.Regexp{"email": regexp.MustCompile(`...`)}会编译失败 - 函数内多次调用
regexp.MustCompile，哪怕 pattern 相同，也得不到复用，每个 goroutine 都在重复编译
包级变量预编译才是真正的“预热”
预热不是指“第一次调用就快”，而是让正则对象在程序启动时就准备好、全局唯一、线程安全。只有定义为包级变量，才能确保只编译一次，且被所有 goroutine 安全共享。
- 正确写法：
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`) - Go 1.19+ 支持结构体字段默认值：
type Parser struct { urlRe *regexp.Regexp = regexp.MustCompile(`https?://[^/\s]+`) } - 别把
regexp.MustCompile放进init()函数——它和包级变量初始化等价，但可读性差、易引发隐式依赖顺序问题
多协程下 match / find 操作本身是并发安全的
*regexp.Regexp 对象的所有方法（MatchString、FindAllString、ReplaceAllString 等）都可被任意数量 goroutine 同时调用，无需加锁或池化。
- 不需要自己做
sync.Pool缓存正则对象——它本身就是无状态的，复用成本为零 - 但注意：如果正则含捕获组，且你用
FindStringSubmatch，返回的[]byte是原输入的切片，需及时拷贝避免被后续写操作覆盖 - 高频场景下，建议先用
strings.Contains或strings.HasPrefix做粗筛，避开不必要的正则执行（比如日志行过滤前先判断是否含"ERROR"）
动态正则必须用 regexp.Compile，且 error 不可忽略
只要 pattern 来自配置文件、环境变量、HTTP 参数或用户输入，regexp.MustCompile 就是错误选择——它会让整个服务因一条坏规则而崩溃。
- 必须用
regexp.Compile并检查 error：re, err := regexp.Compile(userPattern)<br>if err != nil {<br> log.Printf("invalid regex from user: %q, err: %v", userPattern, err)<br> return<br>} -
regexp.Compile返回的*regexp.Regexp同样并发安全，可缓存到 map 中按 pattern key 复用（需配 LRU 或 TTL 清理） - 永远不要对未验证的 pattern 调用
MatchString——若re是 nil，会直接 panic
FindAllString 的参数，却忘了最廉价的加速是提前用 strings.Index 拒绝掉 90% 的输入；而最隐蔽的风险，是把本该由 Compile 处理的动态 pattern，硬塞进 MustCompile 导致 panic 波及整个服务。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
