不能用std::string::replace循环替换敏感词，因其每次调用触发内存重分配、无法处理重叠匹配与替换后新敏感词，且性能随词量平方级下降；应采用AC自动机构建Trie单次扫描匹配，再按end降序合并区间、从后往前构建结果。
敏感词替换为什么不能用 std::string::replace 循环调用
直接遍历每个敏感词、对 std::string 反复调用 replace 是最常见也最慢的做法。每次 replace 都会触发内存重分配和字符拷贝，且无法避免重叠匹配（比如“abc”和“bcde”在“abcdef”中），导致漏替换或重复处理。
更关键的是：替换后新字符串可能产生新的敏感词（如把“管理员”→“管*理*员”，再遇到“*理*”又触发？虽不常见但逻辑失控）。所以必须一次性扫描+构建结果，而非边改边扫。
- 不要写
for (auto& word : words) s.replace(...) - 若敏感词量级 > 100，性能会随长度平方级下降
-
std::string的replace不支持正则锚点，无法控制匹配边界（如“他”不该匹配“他们”中的子串）
AC 自动机是批量敏感词匹配的实用下限
当敏感词数量超过几十个，且文本长度不定（尤其日志、评论等场景），Aho-Corasick 算法几乎是唯一兼顾时间复杂度与工程落地的选择。它把所有敏感词构建成一棵带失败指针的 Trie，单次扫描就能输出所有匹配位置。
别自己手撸完整 AC 自动机——容易出错且无必要。推荐用成熟轻量实现：aho-corasick（C++17，header-only）或封装好的 cpp-aho-corasick 库。它们支持大小写忽略、全字匹配（通过前后非字母数字字符判断）、以及回调式匹配通知。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 初始化时传入
std::vector<:string></:string>敏感词列表，构建自动机仅需 O(Σ|word|) - 扫描文本时，时间复杂度为 O(n + m)，n 是文本长，m 是总匹配数
- 注意：库默认不处理 Unicode，中文需确保输入是 UTF-8 编码，且匹配按字节进行（对纯中文安全，因 UTF-8 中文为 3 字节且不会被截断）
掩码逻辑必须与匹配位置解耦，避免越界和覆盖
拿到 AC 自动机返回的每个 {start, end, word} 后，不能直接在原字符串上做 substr 拼接——因为多次替换会导致后续索引偏移。正确做法是预存所有匹配区间，排序去重（合并重叠区间），再按从后往前顺序构建新字符串。
例如文本 “abccdef”，敏感词 “bc” 和 “cde”，匹配位置分别是 [1,2] 和 [2,4]。若从前向后替换，第一次替换后字符串变长，第二次位置就错了。而从后往前处理，索引不受影响。
- 用
std::vector<:pair size_t>></:pair>存所有匹配起止下标 - 用
std::sort按end降序排列，再合并相邻重叠区间（next.start ） - 掩码字符建议统一用
'*'，长度等于原词长度；若需固定长度掩码（如统一 4 星），需额外记录原始词长用于对齐 - 避免用
std::string::insert或erase做原地修改——它们内部仍会移动内存
性能敏感场景要绕开 std::string 的隐式拷贝和小字符串优化干扰
在高频脱敏（如网关层每秒万级请求）中，std::string 的 SSO（small string optimization）反而可能成为瓶颈：短文本走栈内存快，但一旦超出阈值（通常 15–22 字节），就会触发堆分配，且每次构造/赋值都可能拷贝。
更可控的方式是预分配目标缓冲区：先用 AC 自动机跑一遍获取总匹配数和位置，估算掩码后最大长度（原文本长 + 替换增益 —— 实际不增，只是星号替代，所以长度不变），然后用 std::string_view 输入 + std::vector<char></char> 输出缓冲，最后 move 构造结果。
- 输入用
std::string_view避免构造临时std::string - 输出缓冲预先
reserve()到原文本长度（掩码不改变长度） - 避免在循环内拼接字符串，改用
buffer.insert(buffer.end(), ...)批量写入 - GCC/Clang 下可加
[[likely]]提示分支预测：匹配成功是小概率事件
match_whole_word_only 选项），否则脱敏结果会不可控。 
