静态正则必须声明为包级变量并用regexp.mustcompile预编译，动态正则须用regexp.compile配合sync.map缓存且检查err、限容防oom，匹配时优先用findstringsubmatch或matchstring避免回溯与内存分配。
静态正则必须用 regexp.MustCompile 声明为包级变量，动态正则必须用 regexp.Compile + sync.Map 缓存并检查 err，否则高频调用下 CPU 会卡在编译阶段。
为什么不能在函数里反复调用 regexp.MustCompile
它看起来不报错，但每次调用都会触发包初始化逻辑（哪怕 Go 内部跳过重复编译），语义上等于“假装每次都在编译”，掩盖真实性能路径。火焰图里 regexp.(*Regexp).Compile 占比常超 30%，就是这么来的。
- ✅ 正确：声明为包级变量，启动时一次性完成
init，后续零开销复用 - ❌ 错误：
func parse(s string) { re := regexp.MustCompile(`\d+`); ... }—— 多余且误导 - ⚠️ 注意：
MustCompile的 panic 在程序启动时暴露，适合硬编码、配置类正则；若 pattern 含变量拼接（如"^" + domain + "$"），必须改用Compile并显式处理err
动态正则怎么缓存才安全
用户输入或运行时拼接的 pattern 无法预编译，但裸调 regexp.Compile 会导致 CPU 爆涨——火焰图里 Compile 占比突增就是信号。
- 用
sync.Map[string]*regexp.Regexp缓存，key 是完整 pattern 字符串（建议先strings.TrimSpace标准化） - 每次
regexp.Compile后必须检查err，不能用_忽略；线上服务中静默失败比 panic 更危险 - 缓存 size 要设上限（比如 1000 条），超出后 fallback 到
strings.Contains或直接拒绝，避免 OOM - Go 1.22+ 可用
LoadOrStore原子操作，避免并发重复编译竞争
FindStringSubmatch 为什么比 FindAllString 快
多数提取场景你只需要原始字节切片，而非新分配字符串。后者为每个匹配结果都新建 string header，GC 压力随匹配数线性增长。
- ✅
re.FindStringSubmatch(b)返回[]byte，直接引用原输入底层数组，零堆分配 - ❌
re.FindAllString对每个结果都分配新字符串，哪怕你后续又转成[]byte - ⚠️ 注意：
FindStringSubmatch要求 pattern 中有捕获组，例如`Bearer (\S+)`✅，`Bearer \S+`❌（返回nil） - 仅判断存在？用
MatchString，它不构造*Regexp对象，比调用FindString更轻量
回溯和 Unicode 标志是隐形性能杀手
预编译只解决“编译开销”，pattern 结构本身决定匹配效率。一个没加锚点、滥用 .*、又开了 (?i) 的正则，照样拖慢服务。
-
<div>(.*)</div>遇到未闭合标签可能卡数秒；改用<div>([^ 或 Go 1.20+ 的原子组 <code><div>(?>[^ <li>中文匹配别写 <code>[\u4e00-\u9fa5]——漏掉扩展汉字和全角标点；也别开(?U)，它对汉字范围无作用 - 纯文本定位（如找
"key="后的值），优先用strings.Index+strings.TrimSpace，比正则快一个数量级
真正容易被忽略的是：正则是否该用，比怎么写更重要。很多场景下，strings 包原生函数已足够，强行套正则反而引入编译开销、回溯风险和维护成本。
