strings.Contains不适合敏感词过滤，因其仅返回bool且内部调用strings.Index后丢弃位置信息，导致需重复扫描文本；多词匹配时时间复杂度升至O(n×m)。AC自动机通过一次构建共享状态机、单次扫描即可完成所有模式匹配，吞吐提升5–50倍，特别适用于日志清洗、弹幕审核等模式固定而文本多变的场景。
为什么 strings.Contains 不适合敏感词过滤
它只返回 bool，内部调用 strings.Index 却丢弃位置信息；若后续还需提取或替换，就得再扫一遍——等于对同一文本做两次完整遍历。更糟的是，多个敏感词就得多轮 Contains，时间复杂度直接变成 O(n × m)（n 是文本长度，m 是词数），500MB 日志里查 200 个词，CPU 火焰图里全是字符串扫描。
AC 自动机比 Trie 树快在哪，什么情况下必须选它
Trie 树单次匹配是 O(n)，但查 k 个词就得跑 k 次；AC 自动机把所有敏感词一次性构建成一个共享状态机，扫描输入文本仅需一次，就能同时产出全部命中项——实际吞吐提升 5–50 倍，尤其适合日志清洗、弹幕审核这类「模式固定、文本多变」场景。
- 必须预编译：
ac.Build()只做一次，不能放循环里反复调用 - 传入
[]byte而非string，避免每次匹配都触发string→[]byte转换 - 若敏感词动态变化（如用户实时提交关键词），别硬套 AC；改用带 LRU 缓存的
map[string]*ahocorasick.AhoCorasick，按 pattern 分桶复用
中文和 emoji 场景下 Trie 插入失败的根源
错误写法：for i := range word { node.children[word[i]] = ... }——这按 []byte 遍历，会把“你好”切成三个非法字节单元，建树成功但匹配永远失败。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 所有环节统一用
[]rune：插入时for _, r := range []rune(word)，匹配时也把输入转成[]rune(text) - emoji ZWJ 序列（如 ??）可能长达 10+ 字节，
len([]rune("??"))是 2，但len("??")是 14；靠len()判断长度会误判 - “café” 和 “cafe\u0301” 字节不同但语义相同，Insert/Contains 前必须先过
norm.NFC.Bytes([]byte(s))归一化
并发过滤时 panic: "concurrent map writes" 怎么根治
不是锁没加，而是 map[rune]*Node 在扩容时底层数组复制会触发竞态——即使外层有 sync.RWMutex，也无法阻止 slice 内部指针被多个 goroutine 同时修改。
立即学习“go语言免费学习笔记（深入）”；
- 节点子树初始化必须前置：
if node.children == nil { node.children = make(map[rune]*Node) }，不能依赖延迟分配 - 高并发场景下，用
sync.Pool复用*TrieNode实例，避免高频 new 导致 GC 尖峰 - 更彻底的解法：把
children改成固定大小数组（如[256]*Node），用 ASCII 字符直接索引，规避 map 扩容问题；UTF-8 多字节字符走 fallback 分支
