应使用 map[rune]node 而不是 map[byte]node，因汉字、emoji 等 utf-8 字符需按 rune（字符）而非 byte（字节）切分，否则前缀匹配逻辑错乱；insert 需标记末节点 isword=true，search 需同时满足路径存在且末节点 isword==true，startswith 仅需路径存在；自动补全应限制数量、避免递归中频繁字符串拼接以减少 gc 压力；nil 指针访问需统一判空防护。
为什么用 map[rune]*Node 而不是 map[byte]*Node
中文、emoji、生僻字等都会超出 ASCII 范围，byte 会把一个汉字拆成多个字节，导致插入和查找失败。比如 "你好" 用 []byte 是 6 个元素，但实际只有 2 个字符（rune）。Trie 的节点必须按字符（rune）切分，否则前缀逻辑完全错乱。
- 插入
"你好"时，应生成两个节点：分别对应'你'和'好'，而不是六个byte值 -
range字符串天然按rune迭代，直接用它遍历最安全 - 如果硬要用
byte，得先[]rune(s)转换，否则自动补全会返回乱码或空结果
Insert 和 Search 的边界怎么处理才不漏匹配
很多人写完发现 Search("ab") 对 "abc" 返回 false，或者 "ab" 被当成不存在——问题出在「是否标记单词结尾」和「是否要求精确匹配」没分清。
-
Insert必须在末尾节点设isWord = true，否则Search永远找不到完整词 -
Search只判断路径存在 + 末节点isWord == true；而StartsWith只需路径存在即可 - 自动补全本质是
StartsWith+ DFS 收集所有isWord == true的路径，不是从根开始穷举
自动补全性能卡在哪？DFS 还是内存布局
小数据量下看不出区别，但词库超 10 万后，纯递归 DFS 容易栈溢出，且频繁分配 []string 切片拖慢速度。真正瓶颈不在算法复杂度，而在 Go 的 slice 扩容和 GC 压力。
- 避免在递归里拼接字符串：
prefix + string(r)每次都新分配，改用bytes.Buffer或预分配[]rune缓冲区 - 限制补全数量（如最多 10 条），一达到就提前
return，别等 DFS 走完整棵树 - 如果词库固定，可考虑用「双数组 Trie（DATrie）」替代，但 Go 标准库无现成实现，维护成本高，一般没必要
测试时 panic: "invalid memory address" 怎么快速定位
90% 是节点指针为 nil 却直接访问子节点，典型场景：遍历 word 时某层 node.children[r] 为空，下一步还继续 node = node.children[r] 然后 node.isWord。
- 每次取子节点后加一行
if node == nil { return false }，尤其在Search和StartsWith中 - 写个辅助函数
getChild(node *Node, r rune) *Node，内部统一判空，避免重复漏判 - 用
go test -race跑并发测试，Trie 本身不自带锁，多 goroutine 写同一棵 trie 会崩得毫无征兆
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
