必须预处理词典、切换双数组Trie、隔离编码处理，否则10万+敏感词下Build卡顿、内存暴涨、并发错乱。
直接上结论：别用默认配置的 github.com/bobusumisu/ahocorasick 跑 10 万+ 敏感词或日志规则匹配——build 会卡住、内存暴涨、并发查询错乱。必须预处理词典 + 切换双数组 trie + 隔离编码处理。
Build 卡住 2s+ 或 panic 的真实原因
AC 自动机不是“扔进去就能跑”的黑盒。它对输入词典有强结构约束，Build 阶段 panic 或耗时飙升，90% 源于词典脏数据：
-
""、"\x00"、纯空白字符串（strings.TrimSpace(s) == ""）会导致节点链断裂，直接 panic - 重复项（如
"password"和"Password"）会让 fail 指针指向歧义路径，匹配位置偏移 - 超长模式串（>256 字节）会撑爆单节点子节点映射表，尤其用
map[rune]*Node实现时，内存非线性增长 - 未排序：不按长度升序 + 字典序排列，前缀复用率低，Trie 节点数多出 30%~50%
中文文本匹配漏词或 panic 的根源在编码
FindAllString() 和 FindAllStringIndex() 只接受 UTF-8 编码的 string。但生产环境里，日志文件、数据库导出、旧系统接口返回的文本常是 GBK、Big5 或无 BOM 的 ANSI：
- 直接传入 GBK 字节流，Go 会按 UTF-8 解码，
rune切分错位 → 匹配起始/结束索引全乱，甚至返回负值 - 别在匹配前用
golang.org/x/text/encoding转码：每次调用都触发堆分配 + 同步锁，高并发下成瓶颈 - 正确做法：源头读取时就解码为 UTF-8
[]byte；或改用基于[]byte的双数组实现（如github.com/iohub/ahocorasick），绕过rune层
10 万模式下必须换双数组 Trie
默认 map[rune]*Node 实现，在 10 万模式时构建耗时超 2s、GC 压力陡增。双数组 Trie（DAT）是唯一可行方案：
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 内存占用降为原来的 1/10：节点压缩为两个
[]int32（base[]和check[]） - 构建速度快约 10 倍：避免 map 扩容和指针跳转
- 注意中文支持：DAT 原生只支持 byte 索引，需额外做字符映射（如 UTF-8 rune → uint16 ID），否则中文会被拆成多个字节误匹配
- 推荐库：
github.com/iohub/ahocorasick（支持[]byte输入 + 可视化）、github.com/grepner/go-ahocorasick的 DAT 分支
并发匹配时游标状态必须隔离
自动机结构只读，但匹配过程中的当前节点、已匹配长度、路径深度等状态必须每个查询独占：
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
sync.Pool复用*Matcher并调Search()—— 游标字段残留上次结果，导致并发交叉污染 - 正确做法：每次调用从 root 开始；或显式传入干净的上下文结构体（含
current *Node字段） - 若用双数组实现，多数库（如
iohub/ahocorasick）已将状态封装进MatchIterator，无需手动管理，但注意不要跨 goroutine 复用 iterator 实例
真正难的不是“怎么写个 AC 自动机”，而是让十万级词典在毫秒内建完、GBK 日志不漏词、1000 QPS 下不出错——这些细节不提前压测，上线后只能靠重启扛流量。
