热路径正则慢主因是反复调用regexp.Compile或误用FindAllStringSubmatch；固定pattern必须声明为包级变量并用regexp.MustCompile预编译，动态pattern需用regexp.Compile配合sync.Map缓存且设上限，匹配优先选MatchString或FindStringSubmatch以减少GC。
热路径里正则匹配慢，八成是 regexp.Compile 被反复调用，或者用了 FindAllStringSubmatch 这类重开销 API。真正瓶颈不在“匹配”，而在“编译”和“结果组织”。
包级变量预编译固定正则
所有硬编码、启动后不变的 pattern，必须提为包级变量，用 regexp.MustCompile 一次性编译。这不是“推荐”，而是强制要求——Go 不会在运行时缓存它，每次调用 regexp.Compile 都会重新解析语法树、构建 NFA、做逃逸分析。
- 错误写法：
func parsePhone(s string) bool { return regexp.MustCompile(`^+?d{11,15}$`).MatchString(s) }—— 每次调用都编译，压测时regexp.(*Regexp).Compile占 CPU 火焰图 40%+ - 正确写法：
var phoneRE = regexp.MustCompile(`^+?d{11,15}$`)，然后直接用phoneRE.MatchString(s) - 注意：别在函数体内写
var re = regexp.MustCompile(...)，Go 初始化顺序不保证，可能触发竞态或延迟 panic
动态 pattern 必须缓存 + 限流
用户输入、租户配置、API 参数拼接出的正则（如 "^" + domain + "\.example\.com$"），不能用 MustCompile，但也不能裸调 Compile。否则高并发下大量 goroutine 同时编译相同 pattern，CPU 直接打满。
- 用
sync.Map[string]*regexp.Regexp缓存已编译实例，key 是原始 pattern 字符串 - 必须加长度限制（如最多缓存 1000 个），否则恶意构造长 pattern 会导致 OOM
- 建议搭配 LRU 清理逻辑，或用
time.Now().UnixNano()做简易 TTL（比如 1 小时未访问即淘汰） - 编译失败必须显式检查
err，nil的*regexp.Regexp后续调用会 panic，比静默失败更难排查
匹配 API 选型直接影响分配和速度
同一正则对象，不同方法的性能差可达 2–3 倍。关键看你要什么：存在性判断、首匹配内容、还是全部捕获组？
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只判断是否匹配：
re.MatchString(s)，比len(re.FindStringSubmatch([]byte(s))) > 0快 40%+，跳过所有子匹配逻辑 - 只取第一个匹配片段（含捕获组）：
re.FindStringSubmatch([]byte(s))，返回[]byte切片，零分配；别用FindAllStringSubmatch(..., 1)，它仍遍历全文 - 需要位置而非内容（比如高亮/切片）：
re.FindStringIndex(s)或re.FindStringSubmatchIndex([]byte(s))，避免拷贝子串 - 注意：
FindStringSubmatch要求 pattern 中有括号捕获组，否则返回nil；若只是想取完整匹配，用FindString更直白
回溯不是问题，但 .* 和模糊量词仍是性能拖累
Go 的 RE2 引擎没有灾难性回溯，但 .* 在长文本中仍退化为线性扫描，且会阻止引擎做某些优化。尤其当后面还跟可选内容时（如 <div>.*?</div>），实际匹配路径变长。
- 优先用否定字符类替代
.*?：比如<div>[^ 比 <code><div>(.*?)</div>更快更可控 - 避免嵌套量词：
d+.*w+不如拆成两步：strings.HasPrefix+regexp.MatchString - 非捕获组
(?:...)比普通括号(...)轻量，不存储匹配内容，减少逃逸和 GC 压力 - 中文匹配别用
[u4e00-u9fa5]，漏字且无扩展性；纯文本定位场景（如找token:后的值），strings.Index+strings.TrimSpace快一个数量级
最易被忽略的一点：regexp.Compile 的开销远大于匹配本身，哪怕 pattern 很短、文本很小。热路径里只要看到它在循环或 handler 内，就该立刻重构——这不是“可能慢”，而是“一定慢”。
