Trie需用类实现，每个节点含children字典和is_end布尔值；insert逐字符建节点并置末节点is_end=True；search须走到底再判is_end，不可仅看路径存在。
怎么用 Python 写一个能跑的 Trie（前缀树）
直接上最简可用结构：每个节点存一个 children 字典和一个布尔标记 is_end，不依赖第三方库，兼容 Python 3.7+。别一开始就搞压缩、双数组或序列化，先让 insert 和 search 跑通。
常见错误是把 is_end 放错位置——它属于「当前节点是否为某个词结尾」，不是「当前节点有没有孩子」。比如插入 "a" 和 "ab"，节点 a 的 is_end 必须为 True，否则查不到单字词。
-
insert要逐字符走，遇到空节点就新建，最后打标is_end = True -
search走到底后，必须检查is_end，不能只看是否走到末尾 - 区分大小写？默认区分；如需忽略，统一转
.lower()再插，但注意原始敏感词可能含大小写语义（如 “iPhone”），得按业务定
敏感词过滤时，Trie 怎么避免漏匹配
问题不在 Trie 本身，而在匹配逻辑：朴素遍历容易漏掉重叠词（如文本 “南京南站”，敏感词有 “南京” 和 “南京南站”）。必须用「所有起点出发的最长匹配」，而不是「找到一个就停」。
典型错误是写成单次 search 就返回，结果 “南京南站” 里只命中 “南京”，后面 “南站” 漏检。正确做法是从每个位置开始，在 Trie 上尽可能往下走，记录所有成功匹配的终点索引，再取最长那个。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 对文本每个下标
i，调用find_longest_prefix(text, i)，内部在 Trie 上持续匹配直到失配或到叶 - 返回匹配长度，用
text[i:i+length]替换，而非只替换第一个匹配项 - 性能影响：最坏 O(n²)，但敏感词少、文本不长时完全可接受；真要优化，改用 Aho-Corasick（AC 自动机），但那是另一套实现
为什么不用 dict 实现嵌套字典就容易崩
有人图省事，用 {'a': {'p': {'p': {'l': {'e': {'#': True}}}}} 手动嵌套，看似简单，实际埋雷。
问题出在键名冲突和缺失处理：如果敏感词含 "app" 和 "apple"，嵌套字典没问题；但一旦出现 "app#"（带符号），# 就和你用来标记结尾的键撞了。更麻烦的是，访问 d['a']['p']['x'] 会抛 KeyError，而 Trie 节点本该安静地返回 “无此分支”。
- 必须用类封装，用
.get(char)而非直接下标访问 - 结尾标记别硬编码为
"#"键，用独立属性node.is_end更清晰、无歧义 - 路径中含 Unicode 或控制字符？类结构天然支持任意 hashable key；嵌套 dict 里键类型混乱极易出错
Python 里 Trie 的内存和速度到底吃不吃紧
纯 Python 实现，10 万敏感词大概占 50–100MB 内存，主要开销在对象头和字典哈希表。比 C 实现慢 3–5 倍，但过滤响应仍在毫秒级——除非你每秒处理 GB 级日志流，否则不用急着换 Cython 或 Rust。
真正卡顿往往来自误用：比如每次过滤都重建 Trie，或在循环里反复 insert 同一批词。Trie 是静态结构，构建一次，复用到底。
- 初始化后把 Trie 实例缓存为模块变量或单例，别放函数里反复 new
- 加载敏感词时用
set去重，避免重复insert浪费时间和内存 - 调试时打印
sys.getsizeof(root)没意义——它只算对象头，不算子节点；要看真实内存，用pympler.asizeof或tracemalloc
复杂点在于边界：多线程读写要加锁，但通常只读；词表热更新需要重建 + 原子替换，不能边插边查；还有 UTF-8 BOM、零宽空格这类隐形字符，预处理不干净，Trie 再准也没用。
