Go敏感词DFA检测三大关键:isEnd必须在循环外标记;匹配需支持重叠(不提前退出);node.children访问前必判空且字符串操作须用rune。

Go 里用 DFA 做敏感词检测,核心不是“能不能跑通”,而是「isEnd设在哪」、「node.Next有没有判空」、「匹配时要不要回溯」这三处——线上一出问题,90% 都卡在这儿。
BuildDICT 中 node.isEnd = true 必须放在循环外
常见错误是把 node.isEnd = true 写在遍历敏感词字符的 for 循环内部,比如:
for _, r := range word {
if _, ok := node.children[r]; !ok {
node.children[r] = &Node{children: make(map[rune]*Node)}
}
node = node.children[r]
node.isEnd = true // ❌ 错!“王”“王八”“王八蛋”全被标为结尾
}
这会导致前缀也被判定为完整敏感词,造成严重误杀。正确做法只在整条路径走完后标记:
- 用
node := root开始,逐个range word走子节点 - 循环结束后再执行
node.isEnd = true - 如果需支持“前缀敏感”(如“王八”和“王八蛋”都算),得额外加字段如
isPrefix,不能复用isEnd
匹配时遇到 "王八羔子" 只返回 "王八"?你没做重叠匹配
DFA 默认单次最长匹配,但实际业务常需捕获所有可能命中项。典型表现:
- 输入
"王八羔子坏",只返回"王八",漏掉更长的"王八羔子" - 输入
"我讨厌王八,也讨厌王八羔子",第二个词直接跳过
根本原因是匹配逻辑在碰到 isEnd == true 后就 break 或 return 了。修复关键点:
- 不要一命中就退出;记录当前位置
pos,然后从pos+1重新进树匹配 - 或用双指针:固定
start,让end推进找最长匹配,找到后start++继续 - 简单场景可用
strings.ReplaceAllFunc+contains判断,但高并发下性能差,不建议上线
node.Next[c] 访问前必须检查是否为 nil
Go 的 map 访问 nil map 会直接 panic,而很多人在构建或匹配时直接写 node.Next[c] = ...,本地小数据测不出,压测时突然崩:
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器,提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象,支持命名依赖等
panic: assignment to entry in nil map
堆栈指向 AddChild 或匹配循环里的 node.children[char]。安全写法只有两种:
- 每次读写前手动判空:
if node.Next == nil { node.Next = make(map[rune]*Node) } - 封装成方法:
func (n *Node) getChild(r rune) *Node和func (n *Node) setChild(r rune, child *Node),内部统一处理nil
别图省事跳过这步——线上 panic 往往就来自一个没初始化的 map。
所有字符串操作必须用 []rune 或 for _, r := range word
中文、emoji 等 Unicode 字符在 []byte 下会被截断,导致敏感词漏匹配。例如 "王" 是 3 字节 UTF-8 编码,word[0] 只取到第一个字节,后续匹配全失效。
正确姿势只有两个:
- 遍历时一律用
for _, r := range word(Go 自动按rune拆) - 需要索引操作时,先转
chars := []rune(word),再for i := range chars - 如果硬要用
[]byte(比如纯 ASCII 日志),必须提前校验字符集,否则中文一来就漏词
这个点最容易被忽略,也是灰度发布后才发现“某些词怎么总不命中的”根源。
golang免费学习笔记(深入):立即使用
在学习笔记中,你将探索golang的核心概念和高级技巧!










