结论：小文件用strings.replaceall或newreplacer，大文件必须流式处理；正则仅用于模式匹配，硬套正则替换固定字符串性能差5–10倍。
直接说结论：小文件用 strings.ReplaceAll 或 strings.NewReplacer，大文件必须流式处理；正则只在真要匹配模式时才上，硬套正则替换固定字符串是典型性能浪费。
strings.ReplaceAll 和 strings.Replace 的 n 参数怎么填才不翻车
很多人调 strings.Replace 后发现只换了一处，不是函数坏了，是第四个参数 n 被当成了“是否全局”的开关——它其实是“最多换几次”：
-
n == -1：替换所有匹配项（这才是你要的“全局”） -
n == 0：完全不替换，直接返回原字符串 -
n == 1：只换第一个，适合修正开头格式或去重首标签
strings.ReplaceAll 就是 strings.Replace(s, old, new, -1) 的封装，语义清晰、少一个出错机会。除非你真需要“只换前 3 次”，否则默认用 strings.ReplaceAll 更安全。
多对一替换：NewReplacer 比链式 ReplaceAll 快且稳
要同时把 "password"、"token"、"api_key" 全替成 "***"，别写一长串 strings.ReplaceAll(strings.ReplaceAll(...))——它会扫 3 遍原文本，中间还生成 2 个临时字符串。
-
strings.NewReplacer构建一次，内部按长度降序预排序，单次扫描完成全部替换 - 参数必须成对，个数为偶数，否则运行时报
panic: strings.NewReplacer: odd number of arguments - 规则里不能有空字符串作为 key，Go 1.22+ 会直接 panic
- 它不递归替换：
strings.NewReplacer("a", "b", "b", "c")对"a"输入只产出"b"，不会变成"c"
示例：r := strings.NewReplacer("password", "***", "token", "***")，然后 r.Replace("user:pass password=123 token=abc") → "user:pass password=*** token=***"。
大文件逐行替换：别把整个文件读进内存
几百 MB 的日志文件，用 os.ReadFile + strings.ReplaceAll 很可能触发 OOM。必须用 bufio.Scanner 流式处理：
- 打开原文件后记得
defer f.Close()，新建临时文件也要defer tmp.Close() - 用
scanner := bufio.NewScanner(f)逐行读，每行做strings.ReplaceAll后写入临时文件 - 处理完调
os.Rename("file.tmp", "file")原子替换；跨分区失败时 fallback 到io.Copy+os.Remove - 别漏检查
scanner.Err()，否则 IO 错误会被静默吞掉
常见错误是循环里反复 os.Open 导致 too many open files，或者没处理换行符丢失问题（Scanner.Text() 自动去掉
，写回时得手动补）。
什么时候该切到 regexp？又该怎么避坑
只有当你需要“模式匹配”时才用正则，比如替换所有邮箱、连续数字、URL 中的协议部分。纯字面量替换硬上 regexp.ReplaceAllString，性能差 5–10 倍，还容易因转义出错：
- 想替换字面量点号
.，正则里得写.，Go 字符串中要写成"\."或用反引号`.` -
regexp.MustCompile有编译开销，热路径里别在循环里反复调，定义为包级变量复用 - 避免
regexp.ReplaceAllString("a.b.c", ".", "*")这种写法——.是通配符，结果是"***"，不是"a*b*c" - Unicode 边界要注意：正则若没加
(?U)或范围写窄，可能切开 emoji 或中文 rune 导致乱码
真正容易被忽略的是：正则替换和 strings.ReplaceAll 都不修改原字符串，每次调用都返回新字符串。循环里忘了重新赋值，比如 s = regexp.MustCompile(`d+`).ReplaceAllString(s, "*")，漏了 s = 就白跑了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
