因为敏感词匹配是多模式精确前缀匹配，trie 比 strings.contains 和正则更高效且支持动态增删；aho-corasick 通过 fail 指针实现任意位置匹配，并需正确合并 output、处理 unicode、注意内存与热更新等生产细节。
为什么用 Trie 而不是 strings.Contains 或正则？
因为敏感词匹配本质是「多模式精确前缀匹配」，strings.Contains 会漏掉嵌套词（比如“苹果”和“苹果手机”，前者被后者包含但需独立检测），正则在词表大时编译慢、执行慢、且难以支持动态增删。Trie 把所有敏感词建树，一次扫描就能同步检查所有可能前缀，时间复杂度从 O(n×m) 降到 O(n)，n 是文本长度，m 是词表规模。
注意：Trie 不解决「变形词」（如“苹*果”、“苹 果”），那是另一层预处理问题；这里只管标准字符串匹配。
如何构建带 fail 指针的 Trie（即 Aho-Corasick）？
纯 Trie 只能找完全匹配的前缀，但敏感词常出现在任意位置（如“这个苹果很好”里的“苹果”）。必须加 fail 指针——它指向当前节点失配时该跳转到的最长真后缀节点。Go 标准库没内置 AC 自动机，得手写。
-
Node结构至少含：children map[rune]*Node、isEnd bool（是否为词尾）、fail *Node、output []string（此处存匹配到的敏感词） - 构建
fail指针要用 BFS：根节点的子节点fail全指向根；后续节点的fail= 父节点fail的对应子节点，若无则继续跳fail，直到根或找到 - 别忘了在 BFS 过程中合并
output：当前节点output= 自身词 +fail节点的output，否则会漏短词（如“小”和“小人”同时存在时，“小人”里的“小”要被识别）
匹配时怎么避免重复/遗漏？
常见错误是只在 isEnd == true 时输出，这会漏掉“小人”里“小”的匹配。正确做法是：每走到一个节点，就遍历它的 output 列表并报告所有词。
另一个坑是 Unicode 处理：Go 的 string 是 UTF-8 字节序列，直接用 for i := range text 得到的是 rune 索引，必须用 rune 当 key 存 children，不能用 byte。否则中文、emoji 全乱。
示例片段：
for _, r := range text {
for node.children[r] == nil && node != root {
node = node.fail
}
if node.children[r] != nil {
node = node.children[r]
}
for _, word := range node.output {
fmt.Printf("found: %s\n", word)
}
}
生产环境要注意的三个实际细节
第一，内存占用：每个 Node 的 children map[rune]*Node 在词表大时很占空间。可改用 []*Node + ASCII 优化（对英文为主场景），或用 sync.Pool 复用节点（但需保证线程安全）。
第二，热更新：敏感词库常变。别每次 reload 全量重建 Trie，而是实现增量插入/删除——删除比插入难，建议用「标记删除 + 定期重建」折中。
第三，边界控制：匹配到敏感词后是否截断？是否记录位置？output 里存原词还是带上下文的结构体？这些不写进核心 Trie，但业务调用时很容易忽略——比如替换时不知道原词长度，就会错位。
真正卡住人的，往往不是算法本身，而是中文分词干扰、emoji 占位符、以及「用户输入里混着零宽空格」这种看不见的字符。Trie 再稳，也得先做 clean。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
