必须用 map[rune]TrieNode而非map[byte]TrieNode，因UTF-8中中文、emoji等一字多字节但仅对应一个rune；Search要求路径存在且末节点isEnd=true，StartsWith只需路径存在；DFS补全需防nil访问、避免字符串高频拼接、加数量限制。
Go 里实现 Trie 树，核心不是“怎么写结构体”，而是「字符切分方式」和「空指针防护」两个点没踩准，90% 的 panic 和匹配失败都源于此。
为什么必须用 map[rune]*TrieNode 而不是 map[byte]*TrieNode
中文、emoji、日文等 UTF-8 字符一个字可能占 2~4 个 byte，但只对应 1 个 rune。用 byte 切分会把“你好”拆成 6 个节点，导致插入和查找完全错位。
-
range word天然按rune迭代，直接用最安全，不用额外转换 - 硬要转
[]byte必须先[]rune(word)，否则StartsWith("你好")可能返回空或乱码 - 测试时输入含 emoji（如 "?hello"）就能立刻暴露问题
Search 和 StartsWith 的逻辑差异在哪
很多人写完发现 Search("ab") 对已插入的 "abc" 返回 false，其实是混淆了「单词存在」和「前缀存在」的判定条件。
-
Insert必须在末节点设isEnd = true，否则Search永远找不到完整词 -
Search(word)要求：路径完整存在 且 末节点isEnd == true -
StartsWith(prefix)只要求：路径完整存在，末节点isEnd值无关 - 漏判
isEnd会导致 “搜不到词”；多判isEnd会导致 “前缀误判为完整词”
自动补全为啥一跑就卡住或 panic
补全本质是 StartsWith + DFS 收集所有 isEnd == true 的路径，但 Go 里高频字符串拼接和无限制递归最容易出事。
- 别在递归里写
prefix + string(r)—— 每次都新分配内存，GC 压力陡增 - 改用
bytes.Buffer或预分配[]rune缓冲区，拼接后转string一次完成 - DFS 中加数量限制（如最多 10 条），一达到就
return，别等遍历完整棵树 - 每次取
node.children[r]后必须判空：if node == nil { return }，否则panic: invalid memory address
测试时遇到 invalid memory address 怎么快速定位
90% 是节点为 nil 却继续访问子字段，典型发生于 Search 和 StartsWith 的循环末尾。
- 错误写法：
node = node.children[ch]; if node.isEnd { ... }—— 前一步node.children[ch]可能是nil - 正确写法：取完立即检查，例如
child := node.children[ch]; if child == nil { return false } - 更稳妥的是封装辅助函数：
getChild(node *TrieNode, r rune) *TrieNode，内部统一判空并返回nil - 测试用例优先覆盖单字符、空字符串、含中文/emoji 的词，比纯英文更容易暴露空指针
真正难的不是写完三个方法，而是所有路径分支都覆盖了 nil 防护，且所有字符串操作都避开 rune 到 byte 的隐式降级 —— 这两点一旦松懈，线上一跑带中文的补全就静默失败或 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
