最准方式是运行CPU profile：启动HTTP server后访问/debug/pprof/profile?seconds=30，用go tool pprof打开并执行top -cum搜索compile，若regexp.(*Regexp).Compile出现在热路径，则说明编译逻辑进入hot loop。
直接看 cpu profile 里 regexp.compile 是否高频出现——如果它在 top 3 占比里，基本就是没复用。
怎么确认 regexp.Compile 被反复调用了
最准的方式是跑一次 CPU profile：
- 加
import _ "net/http/pprof"，启动 HTTP server 后访问/debug/pprof/profile?seconds=30 - 用
go tool pprof打开，执行top -cum，搜compile - 如果看到
regexp.(*Regexp).Compile或regexp.compile出现在热路径里，说明编译逻辑进了 hot loop
常见触发点：
- HTTP 中间件里每次请求都
regexp.Compile(req.URL.Path) - 结构体方法里每次调用都 new 一个
var re = regexp.MustCompile(...) - 包级变量写成函数内
init()但被多个 goroutine 竞态初始化（极少见，但可能）
为什么 golangci-lint 本身不会报这个错
golangci-lint 不分析运行时行为，它只扫 AST 和类型信息。正则是否复用属于性能实践问题，不在任何 linter 的检测范围内。
但它能间接帮你发现风险点：
-
staticcheck启用后会报SA1028: use of regexp.MustCompile in non-global scope—— 这是唯一能抓到「非包级复用」的规则 - 如果你在函数里写了
regexp.MustCompile(`\d+`)，staticcheck就会标红；但regexp.Compile+if err != nil则完全逃逸检测 - 所以必须显式启用
staticcheck，且不能禁用它的 SA 规则组
如何让 golangci-lint 帮你守住这条线
在 .golangci.yml 里强制约束正则声明位置：
linters-settings:
staticcheck:
checks: ["SA1028", "SA1030"] # SA1028 抓非全局 MustCompile，SA1030 抓未检查 Compile error
linters:
enable:
- staticcheck
- govet
- errcheck
注意两点：
-
SA1028只对MustCompile生效，对Compile无效——所以日常应优先用MustCompile，把 panic 暴露在 init 阶段 -
SA1030会揪出re, _ := regexp.Compile(...)这种忽略 error 的写法，避免静默失败导致匹配永远为 false - 别信
unused：它可能把包级var emailRe = regexp.MustCompile(...)当作未使用而误报，需在变量名后加//nolint:unused
真正难防的是动态拼接正则（比如 fmt.Sprintf(`^%s/\d+$`, tenant)），这种没法预编译，只能靠 sync.Map[string]*regexp.Regexp 缓存并设 LRU 清理——但 golangci-lint 对此无能为力，得靠压测和 profile 定位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
