高并发下 regexp.compile 会拖垮 cpu，因为每次调用都要解析语法、构建 nfa 状态机，纯 cpu 密集且无法复用；应提前全局编译固定正则，动态正则需缓存并设限，匹配时选对 api。
为什么高并发下 regexp.Compile 会拖垮 CPU
因为每次 regexp.Compile 都要解析字符串、验证语法、构建 NFA 状态机——纯 CPU 密集型操作，且结果无法复用。压测时 QPS 上不去但单核 CPU 100%，pprof 里 regexp.(*Regexp).Compile 占比异常高，基本就是这个原因。
常见错误现象：HTTP handler 里写 re, _ := regexp.Compile(`\d{11}`)，每秒 1000 次请求 = 每秒编译 1000 次，性能损耗远超匹配本身。
- 固定正则（如硬编码的邮箱、手机号格式）必须提前编译，全局复用
- 动态拼接的正则（如
"^" + domain + "$"）不能用MustCompile，否则 panic 不可控 -
MustCompile在init阶段 panic，错误暴露早；Compile返回error，必须显式检查，否则线上静默失败
包级变量 + MustCompile 是最安全的预编译方式
对已知合法、不依赖运行时输入的正则，直接声明为包级变量并用 MustCompile：
var emailRE = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
这样编译发生在程序启动时，后续所有 goroutine 并发调用都复用同一个 *regexp.Regexp 实例——它线程安全，无锁，零 runtime 编译开销。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 别在函数里写
var re = regexp.MustCompile(...)：Go 不保证函数内常量初始化顺序，可能触发竞态或延迟 panic - 别在循环里重复调用
MustCompile：虽然 Go 会跳过重复init，但语义误导且无收益 - 若正则含用户输入或租户配置，必须改用
Compile，且不能忽略err
动态 pattern 必须缓存，但得防内存泄漏
用户搜索关键词转正则、租户自定义路由规则这类场景，pattern 是运行时生成的，只能按需编译，但必须缓存：
- 用
sync.Map[string]*regexp.Regexp做 key-value 缓存，key 是原始 pattern 字符串 - pattern 要标准化：trim 空格、统一大小写、归一化量词（如把
.*?替换为[^]*），提升命中率 - 加长度限制：缓存最多 1000 个 pattern，超限时按 LRU 或时间戳清理旧项，否则 OOM
- 避免 key 冲突覆盖：不同 goroutine 同时编译相同 pattern 时，用
LoadOrStore原子操作，防止重复编译
匹配时选错 API 一样白优化编译
编译再快，匹配 API 用错了也白搭。高频场景下：
- 只判断是否存在？用
re.MatchString(s)，比len(re.FindAllString(s, -1)) > 0快 40%+ - 只取第一个匹配子串？用
re.FindStringSubmatch([]byte(s))，返回[]byte，零分配；别用FindAllStringSubmatch再取[0] - pattern 有捕获组才返回非 nil：比如想提取
Bearer ([^ ]+)中的 token，写成Bearer [^ ]+会导致FindStringSubmatch返回nil - 源数据已是
[]byte？直接传入，别转成string再转回[]byte，隐式 copy 很伤
真正卡住服务的，往往不是正则写得不够“高级”，而是编译没复用、API 选重了、缓存没设限——这些点漏掉一个，前面所有优化都打折扣。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
