正则匹配慢主因常是编译开销或模式退化；应复用regexp.MustCompile全局实例、覆盖多长度输入测非线性增长、构造易退化样例，并优先用FindString/FindSubmatch避免隐式转换。
正则匹配慢，八成不是匹配本身慢，而是编译开销或模式退化——直接用 go test -bench + pprof 定位，别猜。
怎么写可复现的基准测试（go test -bench）
基准测试必须复用已编译的 *regexp.Regexp 实例，否则测的是 Compile 而非匹配；同时要覆盖典型输入长度和边界情况。
- 把
regexp.MustCompile提到全局变量或benchTest函数外，避免每次BenchmarkXxx都重编译 - 用不同长度输入跑对比：空串、10 字符、1KB 日志行、100KB 文本块——看耗时是否随长度非线性增长
- 显式构造易退化输入：比如对
.*@.*\..*传入"a@a.a.a.a.a...@"（大量点+@），观察是否卡住 - 示例写法：
var emailRE = regexp.MustCompile(`^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$`) func BenchmarkEmailMatch(b *testing.B) { s := "test@example.com" for i := 0; i < b.N; i++ { emailRE.MatchString(s) } }
如何用 pprof 抓真实瓶颈（runtime/pprof）
压测时 CPU 满载但 QPS 上不去？pprof 能一眼看出是 regexp.compile 占比高，还是 regexp.(*Regexp).doExecute 在死磕文本。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在 HTTP handler 或主循环里加
pprof.StartCPUProfile，跑 30 秒后Stop并保存文件 - 命令行分析：
go tool pprof cpu.pprof→ 输入top -cum，重点看：-
regexp.(*Regexp).Compile高 → 编译没复用，立刻提为包级变量 -
regexp.(*Regexp).doExecute高且调用栈深 → 模式退化，检查.*、嵌套量词、缺失锚点
-
- 别信“我加了
^$就安全”——用strings.TrimSpace(s)后再匹配，比在正则里写^\s*(.*?)\s*$快 3 倍以上
为什么 FindAllString 比 MatchString 慢得多
这不是 bug，是语义差异导致的隐式开销：前者必须扫描全文、预分配切片、拷贝所有匹配结果；后者找到第一个就返回。
立即学习“go语言免费学习笔记（深入）”；
- 只判断“是否含手机号”？用
phoneRE.MatchString(s)，别写len(phoneRE.FindAllString(s, -1)) > 0 - 只需提取第一个邮箱？用
emailRE.FindString(s)，而非emailRE.FindAllString(s, 1)[0]（后者仍会初始化完整切片） - 若原始数据是
[]byte（如 HTTP body），优先用FindSubmatch系列，避免 string → []byte 隐式转换 - 实测：百万次匹配下，
MatchString比等价的FindAllString(..., 1)快 40%+
真正难调的不是语法对不对，而是你没意识到 .* 在 10KB 文本里会触发 RE2 的穷举分割——它不回溯，但它会算遍所有可能的 . 切分点。上线前务必用真实日志样本跑一次 go test -benchmem -cpuprofile=cpu.out。
