必须用 regexp.MustCompile 而非 regexp.Compile，因其在初始化阶段提供“绝对不能失败”的预编译正则对象，适合 100% 确信正确的常量正则；而 Compile 返回 error 需手动处理，Must 版本直接 panic，且预编译更高效、线程安全。
为什么 regexp.Compile 和 regexp.MustCompile 不能混用？
编译正则表达式不是可选操作，而是必须前置步骤；Go 的 regexp 包不支持运行时动态解析未编译的字符串模式。你写的 "\d+" 必须先过 Compile 或 MustCompile 才能用于匹配——直接传字符串进 FindString 会报错。
二者核心区别在于错误处理时机：Compile 返回 (*Regexp, error)，需显式检查；MustCompile 在编译失败时 panic，适合写死的、确定合法的模式（比如硬编码在代码里的路由规则或日志字段提取）。线上服务中若正则来自配置文件或用户输入，必须用 Compile + if err != nil 处理。
-
MustCompile内部就是调用Compile后 panic，没有额外开销，但无法 recover - 重复编译同一模式浪费 CPU，应复用已编译的
*Regexp实例（全局变量或 struct 字段） - 正则字符串含非法转义（如
"\q"）、未闭合括号、嵌套过深等，都会导致编译失败
FindString、FindAllString 和 FindStringSubmatch 怎么选？
匹配结果的类型和粒度决定了函数选择：你需要原始字符串、带分组的字节切片，还是只关心是否命中？
FindString 返回第一个匹配的 string，简单直接；FindAllString 返回所有匹配的 []string，适合提取多个独立片段（如从文本中抓所有邮箱）；而 FindStringSubmatch 返回 [][]byte，保留原始字节视图，且包含捕获组内容（子匹配），适用于需要精确控制内存或处理二进制安全文本的场景。
立即学习“go语言免费学习笔记（深入）”；
- 所有
Find*方法都要求正则已编译，否则 panic -
FindStringSubmatch对应的FindSubmatch接收[]byte输入，避免 string → []byte 转换开销 - 如果正则含捕获组（如
"(\d{4})-(\d{2})-(\d{2})"），FindStringSubmatch返回的每个元素是[]byte切片，其中索引 0 是全匹配，1 是第一组，依此类推
为什么 ReplaceAllString 替换后长度突变，有时结果不对？
替换函数默认按“找到就替换”顺序执行，不回溯，也不感知重叠匹配。典型陷阱是：模式可重叠（如 "aa" 在 "aaa" 中出现两次，但 ReplaceAllString("aaa", "b", "x") 只替换一次，得 "xba"）。
另一个常见问题是替换字符串里含 $1、$2 等反向引用，但你误用了 ReplaceAllString（它不支持反向引用）——必须用 ReplaceAllStringFunc 配合闭包，或更直接地用 ReplaceAllString 的兄弟函数 ReplaceAllLiteralString（字面替换）与 ReplaceAllString（支持 $1）严格区分。
-
ReplaceAllString支持$1、$2和$$（表示单个 $），但ReplaceAllLiteralString把替换串当纯文本 - 若替换逻辑复杂（如根据捕获内容动态生成新字符串），用
ReplaceAllStringFunc+ 闭包更可控 - 注意：所有 Replace 函数返回新字符串，原输入不变；大量替换时考虑用
strings.Builder手动拼接以减少内存分配
性能敏感场景下，regexp 包有哪些隐藏开销？
正则编译本身较重（尤其含回溯的模式），但更隐蔽的开销来自匹配过程：每次调用 FindString 都会隐式创建新 bytes.Buffer 用于内部状态跟踪；含捕获组的正则比无组版本慢 2–5 倍；而最致命的是，Go 的 regexp 引擎不支持 JIT，长文本 + 复杂模式极易触发指数级回溯（如 "a+?b" 在超长 "a...a" 上）。
- 用
regexp/syntax包的Parse+Compile可提前验证语法合法性，避免运行时 panic - 对固定模式（如手机号、身份证号校验），优先用
strings或bytes原生函数代替正则（strings.HasPrefix、strings.Count等快一个数量级） - 启用
regexp的Longest模式（通过Regexp.FindStringIndex等配合手动控制）可缓解部分贪婪匹配问题，但无法根治回溯爆炸
真正难搞的是那些看似简单、实则暗藏回溯的模式，比如 "a*b*c" 在恶意构造的输入上。上线前务必用真实数据压测，别只跑单元测试。
