regexp.Compile 更适合高频匹配，因其返回可复用的 *regexp.Regexp 实例，避免重复编译开销；而 MustCompile 仅适用于启动期静态模式，动态模式必须用 Compile 并检查 error。
为什么 regexp.Compile 比 regexp.MustCompile 更适合高频匹配
频繁调用正则时，每次重新编译会浪费大量 CPU。Go 的 regexp.Compile 返回可复用的 *regexp.Regexp 实例，而 regexp.MustCompile 仅适合启动期已知、永不变更的静态模式（否则 panic 不可控）。生产环境若在 HTTP handler 中直接写 regexp.MustCompile(`\d+`)，每秒千次请求就可能触发明显 GC 压力。
- 预编译后全局复用：定义为包级变量，
var digitRe = regexp.MustCompile(`\d+`)是安全的，但前提是该正则不依赖运行时输入 - 动态模式必须用
regexp.Compile：比如用户上传的搜索关键词转正则，需检查返回 error，不能跳过 - 注意缓存污染：不同 goroutine 并发调用同一
*regexp.Regexp实例是安全的，但不要把编译结果存在 map 里却不加锁——key 冲突时覆盖会导致意外交替匹配逻辑
FindStringSubmatch 和 ReplaceAllStringFunc 的性能差异在哪
前者返回原始字节切片（[]byte），零拷贝；后者强制分配新字符串，且内部会多次遍历源文本。当只需提取子串或判断是否存在时，FindStringSubmatch 或更轻量的 MatchString 更合适。
- 提取邮箱示例：
matches := emailRe.FindStringSubmatch(input) if len(matches) > 0 { email := string(matches) }比emailRe.FindAllString(input, -1)少一次字符串转换开销 - 替换场景优先用
ReplaceAllString而非ReplaceAllStringFunc：后者对每个匹配都调用函数，闭包捕获变量易引发逃逸；前者接受固定字符串，底层用 memmove 优化 - 若替换逻辑复杂（如按匹配内容查数据库），再考虑
ReplaceAllStringFunc，但务必确认该函数无阻塞、无锁、无内存分配
如何避免 .* 导致的回溯爆炸
贪婪匹配 .* 在长文本中极易引发指数级回溯，尤其配合嵌套括号或可选分组时。Go 的正则引擎虽比 PCRE 温和，但仍会在某些边界 case 卡住数秒。
- 改用非贪婪
.*?不解决问题，只是延迟崩溃——真正解法是明确边界：比如匹配 HTML 标签内文本，用`<div>([^` 替代 <code>`<div>(.*)</div>` - 对日志解析等结构化文本，优先用
strings.Split或bufio.Scanner分段后再小正则处理，而非一股脑喂给regexp - 启用超时控制：无法规避复杂正则时，用
context.WithTimeout包裹调用，并捕获regexp: Compile error或 panic（虽然标准库不抛 panic，但自定义 wrapper 可做兜底） - 安全写法是提前判空：
if replacer == nil { return input } result := re.ReplaceAllStringFunc(input, replacer) - 若想实现“匹配但不替换”，用
ReplaceAllString传原匹配内容：re.ReplaceAllString(input, "$0")，其中$0表示整个匹配 - 注意
$1等捕获组引用只在ReplaceAllString和ReplaceAllLiteralString中生效，ReplaceAllStringFunc的回调函数里只能靠FindStringSubmatchIndex手动提取
替换时传入 nil 替换函数为何 panic
ReplaceAllStringFunc 第二个参数是 func(string) string，传 nil 会直接 panic：「invalid memory address or nil pointer dereference」。这不是文档疏漏，而是 Go 显式拒绝模糊语义的设计选择。
立即学习“go语言免费学习笔记（深入）”；
regexp 包在简单场景足够快，但一旦出现多层嵌套、超长文本或用户可控输入，编译耗时、匹配时间、内存占用三者会同时失控。最常被忽略的是：没人在压测时专门构造恶意正则输入，直到上线后某次日志轮转突然卡住整个服务。
