基础Trie节点应使用std::array<char,26>存子节点并初始化为nullptr，is_end默认false；insert/search需严格检查每步子节点存在性及末节点is_end，推荐shared_ptr管理内存避免泄漏。
怎么写一个基础但可用的 Trie 节点结构
核心是用数组或哈希表存子节点，C++ 里 std::array<:shared_ptr>, 26></:shared_ptr> 最直观（只处理小写 a–z），比 std::map<char std::shared_ptr>></char> 更快也更省内存。别一上来就用 unordered_map——它在短字符串、固定字符集下纯属过度设计。
容易踩的坑：
• 忘记初始化 is_end 成员为 false，导致未插入的路径被误判为单词结尾
• 把 children 声明成裸指针（TrieNode*），后续手动 new/delete 极易泄漏或悬空
• 在构造函数里没把 children 数组每个元素设为 nullptr，访问未初始化指针直接崩溃
示例片段：
struct TrieNode {
bool is_end = false;
std::array<std::shared_ptr<TrieNode>, 26> children{};
};
insert 和 search 的边界逻辑怎么写才不漏判
关键不是“遍历完字符串”，而是“每一步都得检查当前字符对应子节点是否存在”。比如插入 "ab" 后搜 "a"，不能因为走到 'a' 就返回 true——得看 is_end 是否为 true；而搜前缀（如 startsWith("a")）则只要能走完、不中途断掉就行。
常见错误现象：
• search("abc") 返回 true，但其实只插入了 "ab" —— 没检查最后节点的 is_end
• startsWith("abx") 返回 true，但 "abx" 根本没路径 —— 遍历时没判断 cur->children[idx] == nullptr 就继续循环
• 插入空字符串 "" 失败 —— insert 函数没处理长度为 0 的情况，应直接设根节点 is_end = true
实操建议：
• insert：循环中每步新建节点时，记得把 cur = cur->children[idx] 更新到位
• search：循环结束后，额外加一句 return cur != nullptr && cur->is_end
• startsWith：循环结束只需 return cur != nullptr
为什么不用 new/delete 而推荐 shared_ptr
手动管理内存对 Trie 这种树形结构极其危险：删除某个分支时，得递归释放所有子节点；插入中途异常抛出，裸指针状态立刻失控。而 std::shared_ptr 自动计数，节点无引用时自动析构，代码干净且异常安全。
立即学习“C++免费学习笔记（深入）”；
性能/兼容性影响：
• 小数据量下几乎无感知；百万级插入时，shared_ptr 的原子计数开销略高于裸指针，但换来的是确定性的生命周期
• 不要用 std::unique_ptr —— 它无法共享所有权，合并 Trie 或实现 copy 构造时会卡死
• 如果真要极致性能（如嵌入式场景），可改用对象池 + 索引数组模拟指针，但这是后续优化点，不是起步该碰的
字符集扩展时最容易忽略的兼容点
一旦支持大小写、数字或 Unicode，std::array 索引法立刻失效。这时必须切到 std::unordered_map<char std::shared_ptr>></char>，但要注意：
• char 作 key 时，负值（如某些平台 char 默认 signed）会导致哈希错乱，强制转成 unsigned char 再传入 find()
• 若需支持中文等宽字符，char 不够用，得改用 std::u32string + std::unordered_map<char32_t ...></char32_t>，但内存占用翻几倍
• 更隐蔽的坑：不同 locale 下 std::tolower 行为不一致，统一转小写前先确认是否用了 std::locale::classic()
一句话收尾：Trie 的复杂度不在结构本身，而在字符映射和内存归属的耦合处——那里没测全，后面所有搜索都会飘。
