regexp.compile 必须提前预编译，因其为 cpu 密集型操作，重复调用会严重拖慢吞吐；固定正则应全局使用 mustcompile，动态正则需缓存，且须规避灾难性回溯与误用场景。
为什么 regexp.Compile 一定要提前做，不能每次用都调用
Go 的 regexp.Compile 是 CPU 密集型操作，解析正则字符串、构建 NFA 状态机、做语法检查——这些在运行时重复做，会直接拖慢吞吐。尤其在 HTTP handler 或循环里调用，Compile 可能占到整个匹配耗时的 70% 以上。
实操建议：
- 所有固定正则表达式必须用
var re = regexp.MustCompile(`\d{3}-\d{2}-\d{4}`)全局预编译，别在函数里写regexp.Compile - 如果正则模式来自配置或用户输入，且无法避免动态生成，至少加一层
sync.Map缓存：键是 pattern 字符串，值是 *regexp.Regexp - 注意
MustCompile在 pattern 错误时 panic，线上服务务必用Compile+ 显式错误处理，别图省事用 Must
Go 默认不支持 RE2，别指望自动降级或兼容
Go 标准库的 regexp 是自己实现的回溯引擎（类似 PCRE），不是 Google 的 RE2。这意味着：.* + 复杂嵌套 + 长输入 = 指数级回溯风险，可能卡死 goroutine。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 某条日志解析规则在测试数据上很快，上线后遇到畸形 UA 字符串，CPU 突升 100%，持续数秒才返回
-
regexp.MatchString在超长文本中耗时从毫秒级跳到几秒，且 p99 波动极大
实操建议：
- 禁用所有可能导致灾难性回溯的写法：
(a+)+、(ab*)*、.*foo.*bar—— 这些在 Go 正则里没有 RE2 的线性保障 - 真要 RE2 语义（确定性、O(n) 时间），只能换库：
github.com/wasilak/re2（CGO 依赖）或github.com/nyaxt/otaru（纯 Go 实验性 RE2 移植），但要注意它们不兼容标准库 API - 用
regexp/syntax.Parse做静态分析，提前拦截高危 pattern（如嵌套量词 > 2 层）
哪些场景下 strings 比 regexp 快 10 倍以上
正则不是万能锤。当目标是简单子串查找、前缀/后缀判断、固定分隔符切分时，标准库 strings 函数几乎零分配、无状态机开销，性能碾压。
使用场景对比：
- 检查字符串是否以
"HTTP/"开头 → 用strings.HasPrefix(s, "HTTP/")，别写regexp.MustCompile(`^HTTP/`) - 提取 URL 中
host部分（已知格式为https://host:port/path）→ 用strings.SplitN(url, "/", 3)+strings.TrimPrefix，比FindStringSubmatch快且稳定 - 日志行按空格分割字段 →
strings.Fields或strings.IndexByte手动找位置，比FindAllStringSubmatch少 90% 内存分配
预编译后仍慢？检查 Regexp.FindAllString 类方法的底层行为
FindAllString 和 FindAllStringSubmatch 看似只是返回类型不同，但后者返回 [][]byte，避免字符串拷贝；前者强制把每个匹配结果转成 string，触发额外内存分配和 GC 压力。
性能影响明显：
- 对 1MB 文本做 1000 次匹配，
FindAllString分配约 5MB 临时字符串，FindAllStringSubmatch几乎零分配（复用源字节） - 若后续还要对匹配结果做
strings.TrimSpace等操作，优先用Submatch版本 +unsafe.String（Go 1.20+）转 string，而不是直接用FindAllString
另外，FindStringIndex 比 FindString 更轻量——只返回位置不提取内容，适合“判断是否存在”类逻辑。
正则性能问题往往藏在预编译之后：匹配方法选错、回溯没意识、该用字符串原语却硬套正则。最麻烦的是，这些慢不是报错，而是毛刺、延迟抖动、GC 频繁——得靠 pprof cpu profile 才能揪出来。
