为什么直接用 map[string]*Node 实现 Trie 容易出错
直接用 map[string]*Node 实现 Trie 有个坑：Go 字符串的索引操作返回的是 byte 而不是 rune，而 Trie 需要按字符逐层展开。遇到中文、emoji 等多字节字符时，就会被错误切分成单个字节，自然就出错了。比如 "你好"[0] 拿到的是首字节 0xe4，根本不是完整的“你”字。
那么，实际操作中应该怎么做呢？
- 节点子节点用
map[rune]*Node，而非map[string]*Node，彻底避免多字节字符截断 - 插入/搜索时用
for _, r := range word遍历rune，不依赖下标 - 若确定只处理 ASCII（如纯英文域名、ID），可用
map[byte]*Node，性能略高
Insert 和 Search 函数必须区分「前缀存在」和「单词完整结束」
新手常犯的错误是把 isEnd 字段漏掉，或者在 Search 里只检查路径是否存在，没确认最后节点的 isEnd == true。结果 Search("app") 对 ["apple"] 返回 true，这显然不对。
具体来说，需要留意以下几点：
- 每个
Node必须带isEnd bool字段，仅当完整单词插入完毕才设为true Search(word)走完所有rune后，必须额外判断node != nil && node.isEndStartsWith(prefix)则只需走到末尾不为空即可，不用管isEnd
内存泄漏风险：Node 指针循环引用不会触发 GC
Go 的 GC 基于可达性分析，只要从根对象能到达就不会回收。Trie 中若用 parent *Node 字段构建双向链表，又没手动清空，整棵子树会长期驻留内存，造成泄漏。
靠谱的做法：
- 标准 Trie 不需要
parent指针——插入/搜索都是单向向下，加了反而增加维护成本 - 如果真要支持删除（
Delete），采用后序遍历 + 引用计数，或者直接重建子树，不要靠parent回溯 - 用
runtime.ReadMemStats对比插入前后HeapInuse，验证无异常增长
实际项目中该不该自己写 Trie？
90% 场景下，用 map[string]struct{} 做前缀过滤更简单；只有高频前缀匹配（如敏感词过滤、自动补全）、且数据量大（>10 万词）、内存敏感时，才值得上 Trie。
几个实用建议：
- 先用
map[string]struct{}+strings.HasPrefix快速验证逻辑，再决定是否重构 - 生产环境优先考虑
github.com/derekparker/trie或github.com/tidwall/btree（配合前缀扫描），避免手写 bug - 如果词典固定，可预生成跳转表（类似 Aho-Corasick），比基础 Trie 匹配快 3–5 倍
真正难的不是写对 Insert 和 Search，而是想清楚：你要匹配的是字节、rune 还是 Unicode grapheme cluster；要不要支持模糊匹配；删词时是否允许并发读——这些决定了结构要不要加锁、字段怎么设计、甚至该不该用 Trie。
