Trie 优于 substr() 或 find() 是因前缀匹配频繁且字符串集固定，时间复杂度从 O(N×M) 降至 O(M)；其节点用 std::unordered_map 和 std::unique_ptr 管理子节点，仅存 is_end 标记，避免冗余字段与内存泄漏。
为什么用 Trie 而不是 substr() 或 find() 做前缀匹配？
因为前缀匹配频繁、字符串集合固定（比如词典、URL 路由、命令补全），Trie 能把时间复杂度从 O(N×M) 降到 O(M)，M 是待查前缀长度，N 是总字符串数。暴力遍历所有字符串调用 substr(0, len) == prefix 在数据量稍大时明显卡顿；而 std::string::find() 是子串查找，不专用于前缀，且无法复用公共前缀路径。
关键点：Trie 不是万能加速器——单次查询少、动态增删极频繁、内存敏感场景下，它反而比哈希表或排序+二分更重。
TrieNode 的成员设计和内存安全怎么处理？
每个节点只需存子节点指针（26 小写字母可直接用数组，但通用做法用 std::unordered_map<char trienode></char>）和结束标记 is_end。别存冗余字段如 word 或 count，除非业务真需要；否则浪费空间还拖慢构造。
- 用
std::unique_ptr<trienode></trienode>管理子节点，避免裸指针 +new/delete配对遗漏 - 根节点不对应任何字符，
is_end = false，这点容易错写成true - 插入时逐字符走，遇到空指针就新建；查询前缀只需走到末尾，不关心
is_end
示例节点定义：
立即学习“C++免费学习笔记（深入）”；
struct TrieNode {
std::unordered_map<char, std::unique_ptr<TrieNode> children;
bool is_end = false;
};
插入和前缀查询的边界条件有哪些？
空字符串 "" 是合法前缀，也是合法插入项（此时根节点 is_end = true）。但多数业务中空串无意义，建议在接口层提前过滤，而不是让 Trie 处理。
- 插入
"a"后，search("a")应返回 true，startsWith("a")也 true；但startsWith("ab")要求路径存在到'a'后还能走到'b'，否则 false - 大小写敏感：默认按
char值比较，若需忽略大小写，统一转小写再进 Trie，不要在查询时临时转换 - Unicode？标准 Trie 不支持，
char只能处理 ASCII；中文等需改用std::u32string+std::unordered_map<char32_t ...></char32_t>，但性能和内存代价显著上升
完整可运行的最小实现里最容易漏掉什么？
析构函数没写递归释放，导致内存泄漏——这是 C++ Trie 实现被吐槽最多的一点。另外，startsWith() 写成先 search() 再判断长度，本质退化为暴力，完全没利用 Trie 结构。
真正轻量的实现只需要三个函数：insert(const std::string&)、search(const std::string&)、startsWith(const std::string&)。其中 startsWith 必须独立走一遍路径，走到最后字符对应节点存在即可，不用管 is_end。
别为了“看起来完整”加 remove() 或 countWordsWithPrefix() —— 这些操作破坏简洁性，且实际项目中往往有更优替代（比如用 std::set 存所有前缀）。
