敏感词匹配不能用std::string::find做实时过滤，因单次find仅匹配一个子串，而真实场景需同时检测几十至上万条敏感词并支持前缀/后缀/全词匹配、忽略大小写及模糊变形，暴力遍历时间复杂度达O(n×m)，易卡主线程；可行方案是预构建Aho-Corasick自动机实现O(n)扫描，并配合tokenization跳过HTML标签、URL等非文本区域，避免std::regex回溯导致的DoS风险。
敏感词匹配为什么不能用 std::string::find 做实时过滤
因为单次 find 只能匹配一个子串，而真实场景中要同时检测几十到上万条敏感词，并支持前缀/后缀/全词匹配、忽略大小写、甚至模糊变形（如“和蟹”→“和谐”），暴力遍历所有词再调用 find 的时间复杂度是 O(n × m)（n 是文本长度，m 是词库规模），10KB 文本 + 5000 个词就可能卡住主线程。
真正可行的方案是预构建多模式匹配结构。主流选择是 Aho-Corasick 自动机——它把所有敏感词一次性编译成状态机，扫描文本只需 O(n) 时间，且支持失败跳转与输出集合。
实操建议：
- 不要手写 AC 自动机；用成熟封装，比如
aho-corasickcrate（Rust）或 C++ 生态中较稳定的cpp-aho-corasick（注意：不是 Boost.Regex 那种通用正则库） - 若必须原生 C++ 实现，优先基于
std::unordered_map构建 goto 表 +std::vector存 failure link，避免std::map带来的 logN 开销 - 词库加载阶段做归一化：统一小写、去空格、过滤控制字符；否则运行时每次都要做
tolower()，拖慢扫描速度
如何让替换逻辑不破坏原始文本结构（比如保留 HTML 标签、URL、邮箱）
直接全局替换会把 <p>他说了敏感词</p>
<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/6e7abc4abb9f" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">C++免费学习笔记（深入）</a>”；</p> 中的 和 <code>> 当作普通字符处理，导致标签被污染。正确做法是先做轻量级 tokenization，识别出非文本区域再跳过匹配。
不需要完整 HTML 解析器——对大多数业务，用状态机区分 “标签内”、“URL 内”、“普通文本” 三类区域即可：
- 维护一个布尔标志
in_tag，遇到开启、<code>>关闭；在in_tag == true时不触发敏感词匹配 - URL 判断可用简单启发式：匹配
https?://或含@且前后有分隔符（空格/标点），进入in_url状态后跳过匹配 - 替换时保留原始位置偏移，只对纯文本段落调用 AC 自动机；替换后的星号或掩码长度应与原文等宽（中文用
*，英文用*或•），避免布局错乱
std::regex 在敏感词引擎里为什么是陷阱
std::regex 默认使用回溯引擎，当词库拼成一个大正则（如 (敏感|和谐|河蟹|和蟹)），面对恶意构造的输入（如 “和和和和……”）极易触发指数级回溯，造成 DoS。而且 C++11 的 std::regex 实现质量参差不齐，GCC libstdc++ 的性能远低于 Clang libc++，Windows MSVC 更慢。
除非词库固定且极小（std::regex 做主匹配引擎：
- 如果坚持用正则，改用
RE2库（Google 开发，DFA 实现，无回溯），但需自行编译并链接静态库 - 若只是想支持简单通配（如“和*蟹”），可在 AC 自动机基础上加一层前缀树（Trie），对带
*的模式单独走模糊匹配分支，而非塞进正则 - 注意：
std::regex_replace默认替换全部匹配，但敏感词常需“仅首处替换”或“最多替换 3 次”，得手动控制迭代，不能依赖默认行为
内存与线程安全的关键细节
AC 自动机的 state table 本质是一张二维跳转表（state × char → next_state），1 万个词、ASCII 字符集下约占用 2MB 内存；若支持 Unicode（UTF-8 解码后按 codepoint 跳转），内存可能翻 4–5 倍。这不是理论问题——实际部署时，高频服务每请求新建一个自动机实例，会迅速耗尽内存。
必须复用核心结构：
- 将自动机构建结果（goto/failure/output 表）做成全局只读单例，用
std::shared_ptr<const acautomaton></const>管理生命周期 - 每个请求只分配一个轻量级 matcher 对象（含当前 state 和 callback buffer），避免拷贝大表
- 若词库热更新，不能直接 delete 旧实例——需用 RCU（Read-Copy-Update）模式：新表构建完成后再原子交换指针，旧表等所有正在使用的 matcher 完成后才释放
最易被忽略的是 UTF-8 边界处理：直接按字节遍历会切开多字节字符。必须用 std::mbrtowc 或第三方库（如 ICU）做 safe iteration，否则“和蟹”可能被拆成 “和” 和 “蟹”，匹配完全失效。
