regexp.compile在循环中调用会卡cpu，因为每次都要解析正则、构建nfa状态机、做语法校验——纯cpu密集型且无法复用；正确做法是预编译为包级变量，如var digitre = regexp.mustcompile(\d+)，启动时一次性完成，后续零开销。
为什么 regexp.Compile 在循环里一调就卡 CPU
因为每次 regexp.Compile 都要重新解析正则字符串、构建 NFA 状态机、做语法校验——纯 CPU 密集型操作，且无法复用。压测时 regexp.(*Regexp).Compile 在火焰图里占比超 30%，基本就是这个原因。
- 错误写法：
for _, s := range lines { re := regexp.MustCompile(`\d+`); re.MatchString(s) }—— 每次都“假装编译”，实际开销全摊到匹配上 - 正确做法：包级变量声明
var digitRE = regexp.MustCompile(`\d+`)，启动时一次性完成，后续零开销 - MustCompile 适合硬编码正则；动态拼接（如
"^" + domain + "$"）必须用regexp.Compile并显式检查err，否则线上静默失败比 panic 更危险
FindStringSubmatch 为什么比 FindAllStringSubmatch 轻量
FindStringSubmatch 返回 []byte 切片，直接引用原始输入底层数组，零分配；而 FindAllStringSubmatch 会预分配切片并遍历全部可能匹配位置，即使你只取第一个结果，也白跑完整个文本。
- 只需判断是否存在：用
re.MatchString(s)，比len(re.FindStringSubmatch([]byte(s))) > 0快 40%+ - 只需提取首个匹配片段：用
re.FindStringSubmatch([]byte(s))，别用FindAllStringSubmatch再取[0] - 若后续要传给
json.Unmarshal或bytes.Compare，优先选 Submatch 系列，避免隐式string()转换和内存拷贝
.* 和捕获组怎么悄悄吃掉内存
Go 的 regexp 基于 RE2，虽无传统回溯爆炸，但 .* 在长文本中仍退化为线性扫描；而普通捕获组 () 会存储匹配内容，非捕获组 (?:) 才真正轻量。
- 解析 HTML 标签？别用
`<div>(.*)</div>`，改用`<div>([^` 或 <code>`(?s)<div>(.*?)</div>` - URL 协议匹配：用
`(?:https?|ftp)://`，不是`(https?|ftp)://`—— 后者多存一份协议名，徒增逃逸和 GC 压力 - 密码强度校验常用
`^(?=.*\d).{8,}$`，正向前瞻`(?=...)`不消耗字符、不存储结果，比捕获组更省内存 - key 用
strings.TrimSpace(pattern)标准化，避免空格差异导致缓存击穿 - 用
sync.Map[string]*regexp.Regexp，但必须设上限（比如 1000 条），超出后 fallback 到strings.Contains或直接拒绝 - 禁止缓存超长 pattern（如 > 200 字符）或含嵌套量词（如
(a+)+），防 ReDoS 攻击 - pattern 中含 Unicode 或复杂字符类时，
regexp.CompilePOSIX更慢且提示模糊，慎用
动态正则怎么缓存才不爆内存
用户输入或配置生成的正则不能预编译，但裸调 regexp.Compile 会导致 CPU 爆涨 + OOM。缓存必须带限流、标准化和清理机制。
真实场景里，最常被忽略的是：MatchString 和 FindStringSubmatch 这类单次 API 的语义意图，远比性能数字更重要——它们不是“简化版”，而是“精准版”。用错 API 比写错正则更容易拖垮服务。
