std::string_view不能直接当Trie节点键用，因其不拥有内存，若外部字符串析构则视图悬垂；节点应只存char或索引，插入/查询用string_view作零拷贝参数，避免substr分配。
为什么 std::string_view 不能直接当 Trie 节点键用
因为 Trie 节点本身不存完整字符串，只存单字符或字符索引；std::string_view 是为了免拷贝地引用外部字符串而设计的，但如果你把 string_view 存进节点（比如作为 key 或 word 字段），它会依赖外部生命周期——一旦原始字符串析构或移动，所有 string_view 就变悬垂。实际写搜索逻辑时，你真正需要的是：在插入/查询过程中避免对每个前缀做 substr() + std::string 分配。
- 插入时用
string_view当参数入口，逐字符遍历，不生成中间子串 - 节点内只存
char（或uint8_t）和子节点指针，绝不存string_view成员 - 若需记录完整词（如用于
search()返回），可存指向字典池的偏移或 ID，而非视图本身
如何压缩字典使 Trie 内存占用下降 40%+
高频场景（如拼音输入法、URL 路由匹配）中，大量单词共享长公共前缀，但标准 Trie 每个字符占一个节点，导致深度大、指针多、缓存不友好。压缩核心是把「单字符分支」合并为「字符序列边」，即从 trie 变成 **radix tree**（也叫 compact trie）。
- 每个节点不再只存一个字符，而是存一个
std::string_view片段（仅用于构建阶段，不长期持有） - 插入时做路径压缩：若当前节点只有一个子节点，且无结束标记，则合并当前边与子边
- 必须区分「路径压缩边」和「分叉点」：只有度为 1 的非终止节点才可压缩；叶子或分叉点必须保留为显式节点
- 查询时不能简单按字符比，得用
memcmp或循环比对整个边字符串——但实测在 L1 缓存内，比 10 层单字符跳更快
findPrefix() 和 findAllWithPrefix() 的性能陷阱
很多人以为 findPrefix() 只要走到对应节点就完事，其实不然：如果用了路径压缩，目标前缀可能落在某条边中间，而非节点边界上。这时必须额外做「边内查找」，否则漏匹配。
-
findPrefix("abc")可能停在一条边为"abcd"的节点上——需检查前 3 字节是否匹配 -
findAllWithPrefix()更危险：若不做 DFS 剪枝，会遍历所有子树；应先定位到 prefix 结尾节点（或边中断点），再从此处开始 DFS 收集，避免重复扫描根部 - 若支持模糊前缀（如通配符），不要在 Trie 上硬改；建议外挂
Levenshtein或用后缀数组配合，Trie 本身不适合动态编辑边内容
为什么不用 std::unordered_map<char node></char> 做子节点容器
虽然写起来方便，但它让每次字符查找变成哈希计算 + 桶寻址，破坏局部性；而真实场景中英文/ASCII 字符集极小（128 值），用 std::array<node></node> 或位图索引反而更稳。
立即学习“C++免费学习笔记（深入）”；
-
array零成本索引：children[c]是纯地址计算，CPU 可预测，L1 缓存友好 - 内存稍多？确实，128×8=1KB/节点；但现代 CPU 对齐后，比起指针跳转带来的 cache miss，这 1KB 很可能换来 3× 查询速度提升
- 若支持 Unicode（如 UTF-8 字节流），仍可用
uint8_t索引——UTF-8 单字节范围就是 0–127 和 192–247，其余为多字节起始，可统一按字节处理 - 别用
map<char ...></char>：红黑树查找是 O(log k)，k 是子节点数，而array是 O(1)，且编译期可知大小
路径压缩 + 字节级索引 + string_view 入参三者结合后，最易被忽略的是「插入顺序影响压缩效果」：先插 "abcd" 再插 "abce"，和先插 "abce" 再插 "abcd"，可能导致不同压缩形态。如果字典固定，建议排序后批量建树；如果动态更新，就得接受轻微结构抖动——这不是 bug，是 compact trie 的固有 trade-off。
