直接用 map[string]TrieNode 实现 Trie 容易出错，因 Go 中 map 值为只读副本，修改 node.children["a"].IsEnd 不会更新 map 内值；正确做法是用 map[rune]TrieNode 并显式赋值指针，且 Insert 后必须在末节点设 IsEnd = true。
为什么直接用 map[string]*TrieNode 实现 Trie 容易出错
因为 Go 没有引用传递语义，map 的值类型是只读副本——对 node.children["a"] 返回的指针解引用后修改字段，不会自动更新 map 中的值。常见表现是插入后查不到，或 IsEnd 字段始终为 false。
实操建议：
- 始终用指针存子节点：
children map[rune]*TrieNode，而不是map[rune]TrieNode - 插入时必须显式赋值回 map：
node.children[r] = &TrieNode{}，不能写node.children[r].IsEnd = true - 避免在遍历中直接修改 map 值；先获取指针，再通过指针改字段
Insert 和 Search 的边界处理要点
Insert 不只是逐字符建链，关键在结尾节点的 IsEnd 标记是否可靠；Search 则要区分「前缀存在」和「完整单词存在」——前者用 StartsWith，后者必须检查最终节点的 IsEnd。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 输入空字符串
""时 panic：没处理len(word) == 0分支 - 搜索
"a"返回 true，但实际只插入了"aa"：漏判node.IsEnd - 用
byte遍历含中文的字符串导致乱码：应改用rune迭代
推荐写法片段：
for _, r := range word {
if node.children == nil {
node.children = make(map[rune]*TrieNode)
}
if node.children[r] == nil {
node.children[r] = &TrieNode{}
}
node = node.children[r]
}
node.IsEnd = true // 必须放循环外内存占用与性能取舍：children 用 map 还是 [26]*TrieNode
用 map[rune]*TrieNode 支持 Unicode（如中文、emoji），但哈希开销大、GC 压力高；用固定数组 [26]*TrieNode 仅适用于小写英文，但访问 O(1)、无内存分配。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
使用场景判断：
- 词典类应用（如拼音输入法候选词）→ 必须用
map[rune] - URL 路由匹配（如
/api/v1/users）→ 可用map[byte]，但注意'/'和字母数字之外的字符 - 纯英文单词拼写检查 →
[26]*TrieNode更快，但需手动转换r - 'a'
注意：[26]*TrieNode 无法处理大小写混合，若需忽略大小写，应在 Insert/Search 前统一 strings.ToLower，而非在 Trie 内部做转换。
StartsWith 实现时容易忽略的 nil 检查
StartsWith 看似比 Search 简单，但实际更易 panic：只要中间某层 node.children[r] 为 nil，就该立刻返回 false，而不是继续解引用。
典型错误写法：
node = node.children[r] // 若 children[r] 是 nil，下一轮循环 node 就是 nil
if node == nil { return false } // 检查太晚正确顺序：
- 每次取
child := node.children[r] - 立即判断
if child == nil { return false } - 再执行
node = child
这个细节在压力测试中会暴露——高频前缀查询下 panic 频率远高于 Search。
真正难的不是结构设计，而是每个 node.children[r] 访问前后是否都覆盖了 nil 分支，以及 IsEnd 的赋值时机是否严格绑定到单词末尾节点。稍一松懈，就会出现“能插不能查”或者“前缀误判”的静默错误。
