regexp.ReplaceAllString适用于固定字符串全局替换，不支持分组引用；ReplaceAllStringFunc用于动态函数式替换；ReplaceAllStringSubmatch需手动拼接分组结果；正则应预编译避免性能损耗。
regexp.ReplaceAllString 适合简单字符串替换
当你要把所有匹配到的子串替换成固定字符串时，regexp.ReplaceAllString 最直接。它不处理捕获组，只做全局字面量替换。
常见错误是误以为它能引用正则中的分组——其实不能，这时候得换 ReplaceAllStringFunc 或更底层的 ReplaceAllStringSubmatch。
- 输入必须是
*regexp.Regexp实例，不能传字符串正则表达式 - 第二个参数是纯字符串，不支持
$1这类占位符语法 - 如果原字符串里有 Unicode 字符（比如中文、emoji），默认行为正常，无需额外设置
re := regexp.MustCompile(`\d+`)
result := re.ReplaceAllString("订单号：12345，时间：2024-01-01", "XXX")
// 输出："订单号：XXX，时间：2024-01-01"
regexp.ReplaceAllStringFunc 处理动态替换逻辑
当你需要对每个匹配结果做函数式处理（比如转大写、加前缀、根据内容分支替换），用 ReplaceAllStringFunc 更灵活。它把每个匹配项传给函数，返回值作为替换结果。
注意它只接收匹配的字符串本身，不提供原始字符串位置或未匹配部分，所以无法实现“保留上下文再修改”的复杂逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 函数签名必须是
func(string) string - 不会自动跳过空匹配（比如
.*在空字符串上可能反复触发） - 性能略低于
ReplaceAllString，因为多了函数调用开销
re := regexp.MustCompile(`[a-z]+`)
result := re.ReplaceAllStringFunc("Go v1.21 and rust v1.75", strings.ToUpper)
// 输出："GO v1.21 AND RUST v1.75"
regexp.ReplaceAllStringSubmatch 需要手动拼接结果
真正需要提取分组并参与替换时（例如把 user:123 替成 @u123），必须用 ReplaceAllStringSubmatch + 手动遍历。Go 标准库没提供类似 JavaScript 的 $1 插值语法。
这是最容易出错的一环：很多人试图用 ReplaceAllString 加 FindStringSubmatch 混搭，结果漏掉非重叠匹配或拼接错顺序。
- 返回的是
[][]byte，需用string()转换 - 必须自己维护原始字符串偏移，用
FindAllStringIndex配合切片拼接更稳妥 - 如果正则含可选分组（如
(\w+):(\d+)?），对应submatch[2]可能是nil，需判空
re := regexp.MustCompile(`user:(\d+)`)
s := "contact user:1001 and user:2002"
indices := re.FindAllStringIndex(s, -1)
if len(indices) == 0 {
// 无匹配，直接返回原串
}
var result string
lastEnd := 0
for _, idx := range indices {
start, end := idx[0], idx[1]
idBytes := re.FindSubmatch([]byte(s[start:end]))
if len(idBytes) > 0 {
idStr := string(idBytes[0]) // 注意：FindSubmatch 返回 [][]byte，第一个元素才是完整匹配
result += s[lastEnd:start] + "@" + idStr
lastEnd = end
}
}
result += s[lastEnd:] // 补上最后一段
性能与编译缓存：别在循环里重复 Compile
每次调用 regexp.Compile 开销不小，尤其带复杂表达式的。生产代码里几乎都应该用 regexp.MustCompile 配合包级变量，或至少缓存 *regexp.Regexp 实例。
一个典型坑是：HTTP handler 里对每个请求都 Compile 同一个正则，QPS 上去后 CPU 明显升高，而改用预编译后下降 30%+。
-
MustCompile在启动时 panic，适合已知合法的静态正则 - 若正则来自用户输入，必须用
Compile并检查 error，且建议加长度/复杂度限制 - 正则越长、回溯越多（比如
(a+)+b），执行时越容易被恶意输入拖慢
最常被忽略的是 Unicode 边界问题：默认 \w 不匹配中文，要用 \p{L}；^$ 默认按行匹配，多行模式需显式传 (?m)。这些细节不试几次根本意识不到。
