strings.Replacer 适合什么场景
批量、无重叠、纯字符串替换——比如把日志里的敏感字段 password、token、api_key 全替成 "***"，或者统一修正一堆旧 API 路径前缀。它不是正则，不支持模式匹配，也不处理重叠替换（比如用 "ab" → "x" 和 "abc" → "y" 同时存在时，"abc" 不会优先匹配长的）。
常见错误现象：strings.Replacer 对输入不做任何预处理，如果原始文本里有换行、空格缩进不一致，或大小写混杂，它就原样比对——结果就是“明明写了却没换”。
- 只做精确、区分大小写的字面量替换
- 替换顺序无关：内部按长度降序预排序，但你不能靠顺序控制逻辑
- 性能高：构建后是 O(n) 扫描，比多次
strings.ReplaceAll快得多，尤其替换项多时
怎么初始化一个安全可用的 Replacer
别直接传奇数个参数——strings.NewReplacer 接收成对的 old、new 字符串，参数个数必须为偶数，否则 panic，错误信息是：panic: strings.NewReplacer: odd number of arguments。
使用场景：配置驱动的清洗规则（如从 JSON 加载替换列表），这时要校验长度；或硬编码固定映射，建议用变量分组提高可读性。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐写法：
r := strings.NewReplacer("password", "***", "token", "***", "api_key", "***") - 避免写法：
strings.NewReplacer("a", "b", "c")—— 直接崩溃 - 若从 slice 构建，先检查
len(rules)是否为偶数，再用...展开：strings.NewReplacer(rules...)
Replace vs ReplaceAll：别被名字骗了
strings.Replacer.Replace 和 strings.Replacer.ReplaceAll 是同一个方法——ReplaceAll 是 Replace 的别名，Go 源码里就是 func (r *Replacer) Replace(s string) string，文档里写的 ReplaceAll 只是为了语义清晰。调用任一都行，但代码里保持统一。
容易踩的坑：误以为 Replace 只换一次，其实它默认全量替换所有匹配项；也没有 “只换前 N 次” 的选项，需要自己封装。
- 它不会递归替换：比如
r := strings.NewReplacer("a", "b", "b", "c")，对"a"输入得到"b"，不是"c" - 空字符串作为
old值会 panic，错误信息：panic: strings.NewReplacer: empty string as replacement key - 如果
old是" "（空格），可以，但要注意不可见字符是否真的一致
和 strings.ReplaceAll 多次调用比，差在哪
单次调用 strings.ReplaceAll 看似简单，但做 5 个替换就得扫 5 遍原文本；而 strings.Replacer 一遍扫描完成全部替换，内存局部性更好，实测在 10KB+ 文本、5+ 替换项时，快 3–8 倍。
兼容性没问题：从 Go 1.0 就存在，无版本顾虑。但注意它不处理 Unicode 边界问题——比如把 "é"（带重音符的 e）当两个字节看，若你替换的是字节序列而非 rune，可能切坏字符。所以别拿它去处理含复杂 emoji 或非 ASCII 标点的文本清洗，除非你确认输入是纯 ASCII。
- 适合：日志脱敏、模板占位符填充（
"{{name}}"→"Alice"）、HTTP header 值标准化 - 不适合：HTML 标签清理、Markdown 转义、需要上下文判断的替换（如仅替换单词边界内的
"id"） - 性能提示：构建
*Replacer有开销，别在 hot path 里反复NewReplacer，复用实例
strings.Replacer，而是想清楚哪些该它做、哪些不该——比如带格式的文本、需 lookahead/lookbehind 的场景，它连门都进不去。 
