数组变量不适合直接做前缀匹配，因为遍历全量查找时间复杂度为O(n×m)，响应迟钝；而Trie树使查询仅依赖前缀长度，支持O(1)跳转和实时自动补全。
为什么数组变量不适合直接做前缀匹配
用普通数组（如 string[]）存几十万个单词，每次输入就遍历全量查找，时间复杂度是 O(n×m)（n 是词数，m 是平均单词长度）。哪怕只输 1 个字母，也要扫完全部单词——用户还没松手，界面已卡顿。这不是代码写得不好，而是数据结构选错了。
字典树（Trie）的核心优势
Trie 把单词按字母逐层拆解成树状路径：每个节点只存一个字符，从根到某节点的路径拼起来就是前缀。比如插入 "app"、"apple"、"apply"，公共前缀 "app" 只存一次，查它只需走 3 步，不比单词总数有关。
关键点：
- 查询耗时只跟前缀长度有关，和总词量无关
- 支持实时响应：输入 “a” → “ap” → “app”，每步都是 O(1) 跳转
- 天然支持自动补全：走到前缀末尾后，遍历子树就能拿到所有匹配词
用数组模拟 Trie 节点的实用技巧
不用动态指针或 map，也能高效实现 Trie —— 用固定大小的数组替代子节点映射。英文只有 26 个小写字母，可定义：
type TrieNode struct { children [26]*TrieNode; isWord bool }
这样访问 node.children[c-'a'] 是常数时间，无哈希开销，缓存友好。若需支持大小写或符号，可升为 [256] 字节索引，仍保持紧凑。
初始化时一次性分配好结构体数组（如用 slice 预扩容），避免高频 new 分配；终端节点用 isWord = true 标记完整单词，也可额外存词频或 ID 方便业务扩展。
构建与查询的典型流程
构建阶段（仅一次，启动时完成）：
- 遍历原始单词数组，逐字符插入 Trie
- 每插一个词，最多新建 L 个节点（L 是词长），空间占用可控
查询阶段（高频、低延迟）：
- 用户每输入一个字符，沿 Trie 向下走一步
- 若某步 children[c-'a'] == nil，说明无匹配，立即返回空
- 走到当前前缀终点后，DFS 或 BFS 遍历其子树，收集所有 isWord == true 的路径即可得补全列表
整个过程没有防抖、没有延迟等待，输入即响应，适合搜索框、IDE 补全、命令行提示等场景。
