敏感词匹配不能用std::string::find多次扫描，因时间复杂度O(n×m)易卡顿；应使用AC自动机等预构建结构，配合UTF-8字节流处理、右端点降序替换、回调上下文判断及内存复用优化。
敏感词匹配为什么不能用 std::string::find 做多次扫描
因为时间复杂度是 O(n×m)，每次调用 find 都要从头遍历主串，遇到长文本+多关键词时极易卡顿。比如 10 万字文本扫 500 个词，实际可能触发数千万次字符比对。
真正可行的方案是预构建模式匹配结构：AC自动机（Aho-Corasick）或 trie + 多模式匹配优化。标准库不提供，得自己实现或用成熟封装。
- 优先选
aho_corasick库（如 Bogdanp/aho_corasick），轻量、无依赖、支持 UTF-8 字节流 - 若需中文支持，确保敏感词和待脱敏文本都以 UTF-8 编码传入——
std::string本身不关心编码，但匹配逻辑必须按字节边界对齐，不能按char切分 Unicode 字符 - 避免把敏感词存成
std::wstring再转 UTF-8：额外拷贝 + 宽窄转换易出错，直接用std::string存 UTF-8 字节序列更稳
掩码替换时如何避免重复覆盖和越界写入
直接用 std::string::replace 从左到右逐个替换，会因前序替换导致后续匹配位置偏移，比如 “北京” → “**”，再扫 “京津” 就找不到原始位置了。
正确做法是先批量收集所有匹配区间（起始索引 + 长度），再按右端点降序排序后统一替换——这样前面的替换不影响后面区间的坐标。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 匹配结果必须包含原始字节偏移（不是
std::string::iterator，因为replace需要size_t下标） - 替换字符串长度 ≠ 原词长度时（如 “北京” → “**” 是 2 字节，“北京” UTF-8 占 6 字节），要按字节计算偏移修正量，否则后续区间下标全乱
- 别用
std::string::insert或erase动态修改原串：频繁内存重分配拖慢性能，一次性构造新串更快
逻辑替换（非固定掩码）怎么安全调用回调函数
有些场景需要根据词性、上下文做不同处理，比如“苹果”在科技语境替换成 iPhone，在水果语境保留原词。这时不能只靠静态掩码表。
AC 自动机可扩展为带 payload 的节点，在匹配到词时触发用户回调，并传入上下文窗口（前后若干字节）供判断。
- 回调函数签名建议为：
std::string(const std::string& matched, size_t pos, const std::string& context) - context 截取要预留安全边界：UTF-8 中一个汉字可能跨 3 字节，用
std::string的substr直接切容易截断字符，应先用utf8::unchecked::distance（libutf8cpp）或手动找合法 UTF-8 起始位 - 回调里禁止修改正在扫描的原字符串，也不建议做耗时操作（如网络请求、文件读写），否则整个脱敏阻塞
性能关键点：内存复用与零拷贝边界
高频脱敏服务中，90% 时间花在内存分配和字符串拼接上，不是匹配本身。
能复用就复用：AC 自动机对象全局单例初始化一次；匹配结果 vector 提前 reserve；输出字符串用 std::string 的 reserve 预估容量（原始长度 + 替换增益总和）。
- 如果输入是
const char*+size_t len（比如 HTTP body），避免构造临时std::string，直接让 AC 自动机接受指针+长度接口 - 输出若只需写入 buffer 或 socket，考虑用
std::string_view分段返回，而非拼成完整新串 - 调试时打开 ASan 检查
std::string迭代器失效问题——匹配过程中对原串的任何修改都会让之前获取的data()指针失效
