应提前用 regexp.mustcompile 预编译固定正则为全局变量，因其编译开销大、panic 不适合动态场景；用户输入等不确定 pattern 必须用 regexp.compile 并检查 error。
为什么 regexp.Compile 要提前调用，而不是每次匹配都用 regexp.MustCompile
因为正则编译开销大，regexp.MustCompile 在运行时 panic（而非返回 error），一旦正则写错就直接崩，不适合动态 pattern；而 regexp.Compile 返回 *regexp.Regexp 和 error，便于错误处理和复用。
实际项目中，应把固定正则提为全局变量或 init 初始化：
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$`)
若 pattern 来自用户输入（如搜索框），必须用 regexp.Compile 并检查 error：
- 忽略 error 直接使用会导致 nil pointer panic
-
Compile对同一 pattern 多次调用不会缓存，需自行缓存（如用 sync.Map 存已编译的 *regexp.Regexp） - 注意：Go 1.22+ 开始
regexp内部有轻量缓存，但仅限短 pattern 且不跨 goroutine 共享
FindStringSubmatch 和 FindAllStringSubmatch 的区别在哪
前者只找第一个匹配项并返回子表达式（括号内）捕获内容，后者找全部。两者都返回 [][]string，但结构不同：
re := regexp.MustCompile(`(d{4})-(d{2})-(d{2})`)
text := "2023-04-01 and 2024-12-25"
fmt.Printf("%q
", re.FindStringSubmatch([]byte(text))) // ["2023-04-01"]
fmt.Printf("%q
", re.FindAllStringSubmatch([]byte(text), -1)) // [["2023-04-01"] ["2024-12-25"]]
fmt.Printf("%q
", re.FindStringSubmatchIndex([]byte(text))) // [[0 10] [0 4] [5 7] [8 10]] —— 含捕获组位置
-
FindStringSubmatch不返回捕获组内容，只返回整个匹配字符串；要用捕获组得选FindStringSubmatchIndex或FindStringSubmatch配合SubexpNames() - 如果只需要位置（比如高亮或切片），用
XXXIndex系列函数更省内存，避免反复拷贝 string -
FindAllXXX默认最多返回所有匹配，传负数等价于 -1；传正数可限制数量，例如FindAllString(…, 3)只取前 3 个
替换时为什么 ReplaceAllString 常出错，推荐用 ReplaceAllStringFunc 或 ReplaceAllLiteralString
ReplaceAllString 把 replacement 当作字面量，但若其中含 $1、$name 会被解析为捕获组引用——而你可能根本没写括号，或想原样输出 $ 符号。
- 要保留
$字符，必须双写：$$，否则被当成变量引用导致空字符串或 panic - 若 replacement 是动态计算的（比如转小写、加前缀），用
ReplaceAllStringFunc更安全清晰：
re := regexp.MustCompile(`w+`)
re.ReplaceAllStringFunc("Hello World", strings.ToLower) // "hello world"
- 若 replacement 纯字面量且含
$，优先用ReplaceAllLiteralString，它完全不解析$：
re.ReplaceAllLiteralString("price: $100", "USD $100") // "price: USD $100"
性能敏感场景下，哪些正则写法会拖慢匹配速度
Go 的 regexp 基于 RE2，不支持回溯，但某些模式仍会显著变慢，尤其在长文本中：
- 避免
.*开头的 pattern，比如^.*error—— 它强制从每位置尝试匹配，O(n²) 行为 - 用
[^\n]*替代.*限定行内匹配，或改用锚点 + 前缀优化：^error比.*error快几个数量级 - 重复量词嵌套很危险，如
(a+)+b，即使输入合法也可能触发线性放大匹配路径 - 对超长日志行做提取，先用
strings.Index快速筛出疑似段落，再对小片段用正则，比全量跑一遍快得多
真正卡住的时候，别只盯着正则本身——regexp 编译后是不可变的，但频繁 Compile、未复用、或用 FindAllString 返回大量小 string 切片，内存分配压力往往比匹配本身还重。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
