必须用基于[]rune的前缀树+重叠匹配，因strings.ReplaceAll和正则按[]byte处理会导致中文/emoji切分错误、不支持重叠匹配、内存与性能爆炸；Trie需正确设isEnd、判空Next、实现双指针重叠匹配，并支持原子热更新。
直接用 strings.ReplaceAll 或正则暴力替换，线上跑中文、emoji 时大概率漏词或 panic；生产环境必须用基于 []rune 的前缀树（Trie）+ 重叠匹配逻辑，否则一上量就崩。
为什么不能用 strings.ReplaceAll 或正则做敏感词替换
它只支持单次扫描、不支持重叠匹配，且每次调用都生成新字符串副本——500MB 日志文件加载进内存再扫几百遍，GC 直接卡死。更致命的是：strings.ReplaceAll 内部按 []byte 处理，遇到“王八蛋”这种 UTF-8 多字节字符，会把“王”字切在中间，导致匹配永远失败。
- 错误现象：
"王八蛋"被识别成"\xe7\x8e\x8b\xe5\x85\xab\xe8\x9b\x8b"字节流，遍历时取到的不是完整字符，而是乱码字节 - 性能影响：N 个敏感词 × M 字符文本 = O(N×M)，1000 个词 + 10KB 文本 ≈ 百万级操作
- 兼容性风险：正则
regexp.MustCompile编译开销大，且无法精准定位多字节字符起止位置
[]rune 是唯一安全的字符遍历方式
Go 中中文、emoji、生僻字都需用 []rune 表示一个逻辑字符，而非 []byte。所有敏感词插入 Trie 前、文本扫描前，必须统一转成 []rune；遍历也必须用 for _, r := range word，绝不能用 for i := range word（后者遍历的是字节索引）。
- 正确写法：
chars := []rune(text); for _, r := range chars { ... } - 错误写法：
for i := range text { r := rune(text[i]) }—— 这里text[i]是单个字节，不是字符 - ASCII 场景可优化？可以，但必须加校验：
if !utf8.ValidString(text) { return err }，否则中文一来就失效
Trie 构建和匹配时三个必踩的坑
前缀树不是建完就能用，isEnd 设错位置、node.Next 访问前没判 nil、不支持重叠匹配，这三点任一出错，轻则误杀（“王者”被拦），重则 panic（assignment to entry in nil map）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
isEnd = true必须在循环完所有rune后，只在最终节点设置；写在循环内会导致“王”“王八”“王八蛋”全标为结尾 - 每次访问
node.Next[r]前，必须检查：if node.Next == nil { node.Next = make(map[rune]*Node) }；更稳妥是封装getChild(r)和setChild(r, child)方法，内部统一判空 - 重叠匹配不能靠“找最长”，得双指针：固定
start，推进end；命中后记录，start++重新进树；否则输入"王八羔子"只返回"王八"，漏掉更长的"王八羔子"
大文本或日志场景必须流式处理
别把整个文件读进内存再 strings.ReplaceAll，500MB 文件 + 200 个敏感词 = 至少 100GB 内存拷贝。真实可行方案只有两个：
- 分块读取 + Trie 匹配：按行或固定 buffer（如 4KB）读，每块独立走前缀树，替换后 flush 到输出流
- 用
ahocorasick库：它内部已优化多模式匹配与自动机状态转移，比手写 Trie 更稳，且天然支持重叠 - 日志脱敏建议：优先用结构化日志库（如
zap）+ 自定义Hook，在写入前对字段值做 Trie 替换，避免事后扫描
最易被忽略的一点：热更新敏感词时，旧 Trie 实例可能还在被并发请求使用，node.Next 未初始化的分支极易在此刻 panic；必须用原子指针切换 root，且每个节点的 map 初始化逻辑不可省略。
