strings.Replacer 初始化构建DFA简化变体：按old长度降序排序，预处理生成查找表，后续Replace为O(n)零分配扫描；不可变、不支持增删、不递归、不重叠匹配、并发安全。
strings.Replacer 初始化时到底做了什么
它不是简单存个 map，而是构建一个确定性有限状态自动机（DFA）的简化变体：内部把所有 old 字符串按长度降序排序，再对每个位置尝试最长匹配。整个过程在 strings.NewReplacer 调用时完成，之后所有 Replace 调用都是纯扫描，零分配、无回溯。
这意味着：
- 规则越多，初始化越慢，但后续替换越快（O(n) 单次扫描，与规则数无关）
- 不支持运行时增删规则——
*strings.Replacer是不可变对象 - 若传入 100 对替换规则，初始化会做一次预处理，但之后百万次
r.Replace()都复用同一张查找表
为什么“ab”和“abc”同时存在时，“ab”可能先命中
关键不是参数顺序，而是匹配逻辑：strings.Replacer 在每个扫描位置，只取「当前起始位置能匹配的最长 old」；但如果 "ab" 和 "abc" 都是规则，而输入是 "abx"，那 "ab" 匹配成功后，指针直接跳过两个字符，"abc" 根本没机会对齐起始位置。
换句话说：它不做“回退重试”，也不检查更长的前缀是否能从同一位置开始——只贪心取当前可匹配的最长项，且匹配后立即推进指针。
立即学习“go语言免费学习笔记（深入）”；
常见误判场景：
-
strings.NewReplacer("a", "X", "ab", "Y")处理"ab"→ 得"Y"✅ - 但处理
"aab"→ 拆成"a"+"ab"→"X"+"Y"="XY"，而非"Yb"或"XXb" - 想让
"abc"优先，必须确保它在输入中能对齐——比如输入是"abcde"，才能触发"abc"匹配
Replace 和 ReplaceAll 真的是同一个方法吗
是的，源码里 ReplaceAll 就是 Replace 的别名，二者签名、实现、行为完全一致：
func (r *Replacer) Replace(s string) string { ... }
func (r *Replacer) ReplaceAll(s string) string { return r.Replace(s) }
所以：
- 调
r.Replace(s)或r.ReplaceAll(s)结果 100% 相同 - 不存在“Replace 只换一次”的误解——它默认全量替换所有可匹配项
- 没有内置次数限制，不像
strings.Replace(s, old, new, n)那样支持n参数
容易被忽略的边界行为
真正上线出问题的，往往不是主逻辑，而是这些细节：
-
old为空字符串会 panic：strings.NewReplacer("", "x")→panic: strings.NewReplacer: empty string as replacement key - 匹配严格区分大小写、不忽略空白、不 trim——
"Password"不会匹配"password" - 不支持重叠匹配：规则含
"aa"→"x"和"a"→"y"，输入"aaa"结果是"xy"（首两个a→x，剩一个a→y），不是"yy"或"xx" - 并发安全，但构造过程（
NewReplacer）不在热路径上——应提前初始化，避免每次请求都重建
最常漏掉的一点：它不递归，也不关心替换结果是否构成新规则的 old ——这既是限制，也是可控性的来源。需要链式处理时，得拆成多个 Replacer 实例，而不是硬塞进一对里。
