因为std::string::find前缀匹配效率低，批量查询退化为O(N×M)；Trie通过共享前缀结构实现高效前缀查询，核心是is_end标志和children映射，需注意初始化、空字符串处理及内存安全。
为什么不用 std::string::find 做前缀匹配？
因为 std::string::find("abc") == 0 确实能判断是否以 "abc" 开头，但这是单次、静态、O(n) 的操作。当你有成千上万个模式串（比如敏感词、路由路径、单词词典），需要频繁查“是否存在以某字符串为前缀的词”，用暴力遍历或反复调用 find 会退化到 O(N×M) —— Trie 正是为这类批量前缀查询而生的结构。
构建 Trie 节点：别漏掉 is_end 和 children 数组
Trie 不是黑盒，核心就两点：每个节点记录是否为单词结尾，以及指向子节点的映射。C++ 中最常用的是固定大小数组（如 ASCII 字符集用 std::array）或哈希表（std::unordered_map）。前者快且确定，后者省内存但有哈希开销。
常见错误是忘记初始化指针为 nullptr，导致野指针访问；或把 is_end 当作「当前节点是否存字符」——它只表示「从根到该节点的路径是否构成一个完整插入的字符串」。
struct TrieNode {
bool is_end 
= false;
std::array children{};
TrieNode() {
for (auto& p : children) p = nullptr;
}
};
insert() 和 startsWith() 的关键差异
insert(const std::string& word) 必须遍历每个字符，逐层创建新节点，并在末尾置 is_end = true；而 startsWith(const std::string& prefix) 只需走到前缀末尾，不关心那里是不是单词结尾——只要路径存在，就返回 true。
-
search(const std::string& word)则必须走到末尾 + 检查is_end == true - 所有遍历中，遇到
nullptr就立刻返回失败，不能继续 - 注意空字符串：
startsWith("")应返回true（根节点本身即代表空前缀）
内存管理：用 std::unique_ptr 避免裸指针泄漏
手动 new/delete 容易出错，尤其在异常路径下。直接用 std::unique_ptr 替代裸指针成员，让 RAII 自动释放整棵树：
struct TrieNode {
bool is_end = false;
std::array, 128> children{};
};
这样 insert 时只需 node->children[c] = std::make_unique，析构时递归自动清理。不过要注意：如果频繁插入/删除且对性能极度敏感，unique_ptr 的间接跳转可能略慢于裸指针 + 手动池化管理——但绝大多数场景下，安全远胜这点微小开销。
真正容易被忽略的是字符编码边界：用 128 大小数组只支持 ASCII；若要支持 UTF-8 字节流，得按字节解析并确保不会把多字节字符拆开匹配——这时候建议先转 UTF-32 或改用 std::unordered_map。
