最直接的方法是多次调用 strings.ReplaceAll，依次替换每组字符串；适用于小文件且替换规则简单、无顺序依赖的场景。
用 strings.ReplaceAll 批量替换多组字符串最直接
小文件（strings.ReplaceAll 是最快最稳的选择。它不编译正则、无状态开销，纯字面量替换，性能碾压 regexp。
关键点在于：不要链式调用多次 ReplaceAll（会反复拷贝字符串），而是按顺序累积处理，或用 map 预定义规则后单次遍历：
- 先读入全部内容：
content, err := os.ReadFile("file.txt") - 定义替换对：
replacements := map[string]string{"old_a": "new_x", "old_b": "new_y"} - 逐对替换（注意顺序！若存在嵌套如
"a"和"ab"，需先换长的）：for old, new := range replacements { content = []byte(strings.ReplaceAll(string(content), old, new)) } - 写回：
os.WriteFile("file.txt", content, 0644)
大文件必须逐行处理，否则 OOM
读全量到内存对几百 MB 的日志或数据文件是危险操作。此时必须用 bufio.Scanner 流式处理，边读边写临时文件，最后原子替换。
常见错误是忘记关闭文件、未检查 scanner.Err()、或在循环里反复 os.Open 导致 too many open files：
立即学习“go语言免费学习笔记（深入）”；
- 打开原文件：
f, err := os.Open("big.log")，记得defer f.Close() - 新建临时文件：
tmp, err := os.Create("big.log.tmp")，同样要defer tmp.Close() - 用
scanner := bufio.NewScanner(f)逐行扫描，每行做strings.ReplaceAll后写入tmp - 处理完后调用
os.Rename("big.log.tmp", "big.log")；跨分区失败时需 fallback 到io.Copy+os.Remove
需要模糊匹配？regexp.ReplaceAllString 比 FindAll+ReplaceAll 快一倍
当要替换所有邮箱、IP、日期格式等动态模式时，别用 re.FindAllString 找出所有匹配再挨个 strings.Replace —— 这会触发两次正则扫描，实测慢 40%~100%。
直接用编译好的 *regexp.Regexp 实例调用 ReplaceAllString：
- 复用正则对象（避免重复
regexp.Compile）：var emailRe = regexp.MustCompile(`\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b`)</li> <li>替换：<code>newContent := emailRe.ReplaceAllString(string(content), "[EMAIL]") - 若需捕获组内容（比如只取 URL 中的域名），改用
FindAllStringSubmatch，但仅当真要提取而非替换时才值得引入额外复杂度
批量处理多个文件，filepath.Walk 要防踩坑
filepath.Walk 是遍历目录的起点，但默认行为极易出错：它不跳过目录、不忽略隐藏文件、遇到符号链接可能死循环。
安全做法是回调中立刻判断类型和后缀：
- 先
if info.IsDir() { return nil }排除所有目录 - 再用
strings.ToLower(info.Name())统一小写后匹配后缀：strings.HasSuffix(name, ".txt") || strings.HasSuffix(name, ".log") - 遇到
node_modules或.git这类目录，主动返回filepath.SkipDir跳过整棵子树 - 别在 walk 回调里做 I/O 或耗时操作；只收集路径，后续用带缓冲 channel 的 worker pool 并发处理
真正难的不是替换逻辑本身，而是路径合法性校验、编码兼容性（比如 GBK 文件）、以及原地覆盖时的原子性保障——这些细节漏掉一个，批量任务就可能静默损坏几十个文件。
