不能直接用 std::string::find 做敏感词匹配，因其时间复杂度高（o(n×m)）、无法处理嵌套/重叠匹配；应使用 aho-corasick 自动机，需预构建失败指针并反向处理匹配区间以避免下标偏移。
为什么不能直接用 std::string::find 做敏感词匹配
因为敏感词库往往有几百到上万条，逐条调用 find 是 O(n×m) 时间复杂度（n 是文本长度，m 是词数），实际场景中一长段用户输入可能触发几十次全量扫描，延迟明显。更糟的是，它无法处理“嵌套”或“重叠”匹配，比如词表含 "法轮" 和 "法轮功"，单纯顺序查找会漏掉后者或重复替换。
真正可行的路径是预构建自动机：把所有敏感词一次性编译成状态转移图，让文本只扫描一遍 —— 即 Aho-Corasick（AC）算法。标准库不提供，但 std::unordered_set 或 std::map 做前缀树（Trie）是常见误区，它们不支持失败指针（failure link），无法回退匹配，性能仍卡在 O(n×平均词长)。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用现成轻量级实现，比如 Bogdanp/aho-corasick（header-only，C++17，无依赖）；自己手写 AC 时务必实现
build_failure_links()，否则多模式匹配退化为暴力 - 敏感词加载后必须调用
build()或等效初始化函数，否则所有find()调用返回空结果 —— 这是新手最常忽略的步骤 - 词表含中文时，确保所有字符串以 UTF-8 编码传入；AC 自动机本身不解析 Unicode 字符边界，所以“张三丰”和“三丰”这种跨字节匹配不会出错，但若后续要做按字替换（如 * 号遮盖），需额外用 ICU 或
utf8cpp拆分码点
如何在匹配后安全做原地屏蔽（非简单 std::string::replace）
直接循环调用 replace 修改原字符串会导致下标偏移、重复匹配或越界 —— 因为每次替换后后续字符位置全变了，而 AC 的匹配结果是原始坐标。
正确做法是先收集所有匹配区间（start, end, matched_word），再反向遍历处理（从高地址往低地址改），避免偏移干扰。若需保留原始文本结构（如 HTML 中跳过标签内容），还要预扫描标记非文本区域。
实操建议：
- 用
std::vector<:tuple size_t std::string>></:tuple>存匹配结果，size_t用原始std::string的字节偏移，不是 Unicode 字符索引 - 屏蔽符号统一用单个
'*'还是按原词长度打星？前者简单但暴露词长，后者需计算 UTF-8 字节数 —— 推荐用utf8::distance(ptr, ptr + len)（来自utf8cpp）得字符数，再填对应数量'*' - 若业务要求“仅屏蔽首次出现”，在 AC 的
find_all()后加break即可；但注意某些实现默认只返回首个，需查文档确认是否含find_first_only参数
替换时怎么避免破坏 HTML 或 JSON 结构
直接对整段 std::string 扫描替换，会误杀 <div class="法轮"> 里的 class 名，或 JSON 字段名 <code>"illegal_activity": "法轮功" 中的键名 —— 这类场景必须区分“可渲染文本”和“元数据”。
没有银弹方案，但可分级处理：轻量级用正则预切分（如 R"(]*>|[^），对每个匹配块判断是否为标签（以 <code>' 开头）；重度需求应集成 HTML 解析器（如 <code>gumbo-parser），只遍历文本节点（GUMBO_NODE_TEXT）。
实操建议：
- 若仅需过滤富文本中的可见文字，用
html2text先转纯文本再过滤，最后用 DOM diff 映射回原结构 —— 简单但丢失格式 - JSON 场景更棘手：不能简单跳过双引号内内容，因为
"content": "法轮功"是要过滤的，而"type": "illegal"不是。可靠做法是用simdjson解析后递归检查值类型为 string 的字段，再对 value 字符串单独跑 AC 匹配 - 所有结构化数据过滤后，必须重新序列化，禁止拼接字符串 —— 否则引号、转义符错乱会导致解析失败
性能瓶颈常卡在哪儿，怎么验证
实测发现，90% 的响应延迟不在 AC 匹配本身，而在三处：词表加载时未预编译（每次请求都 build()）、UTF-8 解码反复调用、替换后字符串频繁 realloc。
用 perf record -e cache-misses,instructions:u ./your_filter 可定位热点；更直接的是加粗粒度计时：在 ac.search(text) 前后打 std::chrono::steady_clock，对比占比。
实操建议：
- 词表应静态初始化（
static const auto ac = []{ ... return AC(); }();），或启动时一次加载，避免每请求重建 - 避免在循环里 new/delete
std::string；用std::string_view输入 AC，输出匹配位置也用std::string_view指向原文，减少拷贝 - 若需高频替换（如聊天消息流），预分配目标字符串容量：
result.reserve(input.size() + 128);（128 是星号总长上限），防止多次扩容
最易被忽略的是词表更新机制 —— 热更新敏感词时，若用锁保护全局 AC 实例，高并发下会成为瓶颈；更好的方式是用读写锁 + 原子指针切换（std::atomic_load 旧实例，std::atomic_store 新实例），旧实例延迟析构。
