不能直接用std::map或std::unordered_map模拟Trie节点，因其破坏Trie的O(1)确定性跳转、缓存友好性及字典序遍历能力；固定数组（如children[26]）更符合空间换时间与前缀匹配的核心设计。
为什么不能直接用 std::map 或 std::unordered_map 模拟 Trie 节点？
可以模拟，但会掩盖 Trie 的核心设计意图：空间换时间 + 确定性跳转。用哈希表做子节点映射，虽然写起来快，但失去两个关键优势：一是无法按字典序遍历（std::map 可以但开销大），二是无法支持「通配符匹配」「最长前缀匹配」等典型操作的高效实现。真正手写 Trie 时，子节点应是固定大小数组（如 vector<node> children</node> 或原生数组 Node* children[26]），这样访问第 c 个子节点就是 children[c - 'a']，O(1) 且无哈希冲突。
常见错误是把 insert 写成递归但忘了处理空指针，或在 search 中提前返回 false 却没检查当前节点是否为结尾（即 is_end 标志位）。
Node 结构体里必须带 is_end 字段吗？
必须。Trie 不是单纯存储字符串的容器，而是支持「前缀存在性」和「完整词存在性」两种查询。比如插入 "app" 和 "application" 后，前缀 "app" 存在，但它本身也是个单词。没有 is_end 就无法区分「路径走到这里只是中间节点」还是「这里就是一个合法单词结尾」。
容易忽略的细节：
立即学习“C++免费学习笔记（深入）”；
-
is_end初始化必须为false，否则新建节点默认可被search判定为有效词 - 插入时，只在最后一个字符对应节点设
is_end = true，不是路径上每个节点都设 - 如果支持统计词频，可把
bool is_end换成int count，初始为 0
如何支持非小写英文字符（比如数字、大小写混合、中文）？
关键不在字符集本身，而在子节点数组的索引映射方式。小写英文用 c - 'a' 是因为 ASCII 连续且范围可控；换成其他字符必须保证映射后下标不越界、不冲突。
实操建议：
- 纯数字（'0'–'9'）：用
c - '0'，数组大小设为 10 - 大小写英文（'A'–'Z', 'a'–'z'）：统一转小写再算，或用
26 * 2 = 52大小数组，映射函数写成(isupper(c) ? c - 'A' : c - 'a' + 26) - 任意
char（含负值）：不能直接当数组下标，改用unordered_map<char node></char>，但要接受 O(1) 均摊变 O(α)，且丧失顺序性 - Unicode（如中文）：实际项目中基本不用数组，改用
map<char32_t node></char32_t>或第三方 trie 库；手写教学场景下，通常限定输入为 ASCII 子集更清晰
删除操作（erase）为什么比插入和查找难得多？
因为 Trie 是共享前缀结构。删一个词可能只影响末端节点，但也可能连带删掉整条路径——前提是该路径上所有节点都**仅被这一个词使用**。判断「是否独占」需要回溯或引用计数。
最简可行方案（不回收内存）：
- 只把末节点的
is_end设为false，不释放任何节点 - 适用于只增不删、或删除极少的场景（如配置加载）
真正释放内存的方案需额外字段：
- 加一个
int prefix_count字段，每次插入经过某节点就 ++，删除时 -- - 从末节点向上回溯，对每个父节点检查：若
prefix_count == 0且is_end == false，则可安全delete并置父节点对应指针为nullptr - 注意：回溯需保存路径（如用
stack<node></node>），且必须确保多线程不并发修改同一路径
实际项目中，除非内存极度敏感，否则优先用「惰性删除」+ 定期重建 Trie，比实时回收更稳。
