基础 trie 节点应使用 std::unordered_map children 和 bool is_end = false；insert 遍历完后必须设 is_end = true，search 需检查指针存在且 is_end == true 才返回 true。
怎么手写一个基础 Trie 节点结构
标准 std::map 或 std::unordered_map 做子节点映射，比用固定大小数组（如 children[26]）更通用、更省内存，尤其处理 Unicode 或混合字符时。但要注意：std::unordered_map 在频繁插入小字符串时可能因哈希开销略慢；std::map 有稳定 O(log k) 查找（k 是当前节点子节点数），且迭代有序，适合后续做前缀枚举。
常见错误是把 is_end 标志位和实际插入的字符串数量混淆——它只表示“到这里是否构成一个完整单词”，不是计数器。如果需要统计词频，得单独加 int count 字段。
示例结构体：
struct TrieNode {
std::unordered_map<char, TrieNode*> children;
bool is_end = false;
};
insert 和 search 的边界逻辑怎么写才不漏判
核心在于遍历完字符串后，insert 必须设 node->is_end = true；而 search 不仅要走到末尾，还必须检查该节点 is_end == true。很多人写 search 时只判断指针非空就返回 true，结果把前缀当成完整词匹配了。
立即学习“C++免费学习笔记（深入）”；
无序列表要点：
-
insert过程中，每步都要检查当前字符是否存在，不存在就 new 一个新节点再挂进去 -
search遇到某字符找不到子节点，立刻返回false；走完循环后必须多一句return node->is_end - 如果支持空字符串插入，初始化后就要设根节点
is_end = true，否则search("")永远失败
用 vector 做前缀查询会爆内存吗
不会直接爆，但效率极差——暴力扫所有单词调 substr 或 starts_with 是 O(N×L)，N 是字典大小，L 是平均长度；而 Trie 前缀遍历是 O(P + M)，P 是前缀长度，M 是匹配出的单词总数。
正确做法是先 walk 到前缀末尾节点，再从那里 DFS 收集所有 is_end == true 的路径。注意递归栈深度 = 最大单词长度，一般没问题；但如果字典里有超长路径（比如上万字符），要考虑手动栈或限制深度。
容易踩的坑：
- DFS 时不保存路径字符串，而是边递归边拼接，避免重复拷贝
- 别在每次递归都新建
string，用引用传入并 push/pop 字符更高效 - 如果只要数量不要具体字符串，就别构造
vector<string></string>，直接计数
std::shared_ptr 有必要吗
绝大多数场景没必要。Trie 是典型单所有权结构：插入、删除、查询都从根开始，没有共享引用需求。用裸指针 + 手动 delete 更轻量，也更容易控制释放时机（比如封装成 Trie 类，在析构里递归 delete）。
只有两种情况值得考虑 shared_ptr：
- 多个线程并发读写同一棵 Trie（但这时更该用读写锁 + 裸指针）
- 需要把子树切出来复用，且生命周期不确定（极少见）
滥用 shared_ptr 会拖慢插入速度（原子计数）、增加内存占用（每个节点多 16 字节控制块），还可能因循环引用导致泄漏——比如节点存了父指针。
复杂点其实不在结构本身，而在你是否真需要动态增删。如果字典完全静态，建好就只读，那用双数组 Trie（DAT）或 AC 自动机反而更省空间、更快；但手写难度高，调试成本大，多数人还是老老实实写个带 unordered_map 的 Trie 更稳。
