AC自动机比暴力find快得多，时间复杂度从O(n×m)降至O(n+k)，实测10万字+1000词仅需0.3ms；应使用aho-corasick等轻量库，避免Boost；需预处理去重、转小写、归一化模糊变体；匹配后须逆序替换或拼接新字符串以保偏移；热更新推荐双实例切换或版本号懒加载。
敏感词匹配用 AC 自动机比暴力 find 快得多
纯用 std::string::find 在长文本里逐个扫描敏感词，时间复杂度是 O(n×m)，n 是文本长度、m 是敏感词总长度。10 万字文本 + 500 个词，可能卡住几十毫秒——用户发消息时明显卡顿。
AC 自动机（Aho-Corasick）把所有敏感词构建成一棵带失败指针的 Trie，单次扫描就能找出全部匹配位置，复杂度降到 O(n + k)，k 是匹配总数。实测 10 万字 + 1000 词，平均 0.3ms 内完成。
别自己手写 AC；用成熟轻量库更稳：aho-corasick（C++17，头文件仅 200 行）、或 cpp-aho-corasick。避免用依赖 Boost 的方案——只为了敏感词引入整个 Boost 太重。
构建时注意：词表需去重、剔除空串、按长度或频次排序（影响构建速度但不影响匹配）；插入前统一转小写（若不区分大小写），否则运行时还得做 case-fold。
立即学习“C++免费学习笔记（深入）”；
屏蔽逻辑必须保留原始位置和上下文
直接用 std::string::replace 挨个替换会破坏偏移，导致后续匹配错位。比如 “法轮功” 被替成 “***”，后面 “轮功邪教” 就再也匹配不上了——因为中间字符被覆盖，Trie 节点跳转断链。
正确做法是先用 AC 自动机跑一遍，收集所有 std::vector<:pair size_t>></:pair>（起始、结束下标），再逆序处理（从后往前 replace），或生成新字符串拼接：
std::string masked;
size_t last = 0;
for (const auto& [start, end] : matches) {
masked += text.substr(last, start - last);
masked += "***";
last = end;
}
masked += text.substr(last);
如果要支持「部分屏蔽」（如“法*功”），记得在收集匹配时保存原始子串，再按规则映射；不要在 AC 匹配阶段做替换——那会污染状态机。
替换策略得由业务决定，不能全靠正则
有人想用 std::regex_replace 做模糊替换（比如“法#轮#功” → “***”），但正则在敏感词场景极易误杀、性能差、且无法复用 AC 的多模匹配优势。正则适合兜底，不适合主流程。
真正要支持模糊变体（拼音、谐音、星号分隔），应在预处理阶段归一化：对输入文本做一次轻量转换（如去除标点、转拼音首字母、合并空格），再喂给 AC 机；敏感词词表也提前存好这些变体。例如：“fa*lun*gong”、“法 轮 功” 都预先转成 “falungong” 后加入 Trie。
注意：拼音转换用 pypinyin C++ 绑定太重，推荐用静态映射表（std::unordered_map<char std::string></char>）做 ASCII 字母映射，中文用预生成的 2000 常用字拼音表（约 100KB），加载进内存即可。
线程安全与热更新的实际约束
AC 自动机实例本身是只读的，构建完可安全多线程共享；但词表更新必须重建整个 Trie。别试图加锁修改内部节点——失败指针结构不允许增量更新。
热更新方案只有两种可行路径：
- 双实例切换：后台线程构建新 Trie，构建成功后原子交换指针（用
std::atomic<:shared_ptr>></:shared_ptr>） - 版本号+懒加载：每次匹配前检查版本号，不一致则触发 reload，首次访问时阻塞构建（适合低频更新）
别用文件监听+自动 reload——万一词表格式错误，新 Trie 构建失败，旧实例又已被释放，服务就直接 crash。至少留一个 fallback 词表硬编码在代码里。
最后提醒：AC 自动机不解决语义识别（比如“苹果手机” vs “苹果公司”）。真要分场景，得上分词+词性标注，那已超出字符串匹配范畴——先确保基础匹配稳了，再考虑加 NLP 层。
