不能直接用 std::string::replace 做敏感词脱敏，因为其单次替换仅支持固定位置、无法处理重叠匹配与全量扫描，暴力循环 find+replace 时间复杂度为 O(n×m)，且替换后可能引入新敏感词；AC 自动机是唯一高效方案，可单次扫描完成多模式匹配，时间复杂度 O(n+m+z)，但需注意 UTF-8 边界、内存分配与掩码策略等周边性能瓶颈。
为什么不能直接用 std::string::replace 做敏感词脱敏
因为单次 replace 只能匹配固定位置，而敏感词出现在任意偏移、可能重叠（如“北京”和“京华”）、且需全量扫描——暴力循环调用 find+replace 是 O(n×m) 时间复杂度，文本越长、词库越大，性能断崖式下跌。更糟的是，替换后可能引入新敏感词（如把“枪”→“**”，再出现“**支”被误判），必须做一次扫描、一次处理、零回溯。
AC 自动机是唯一靠谱的底层选择
多模式匹配必须用 AC 自动机（Aho-Corasick），它把所有敏感词构建成一棵带失败指针的 Trie 树，单次扫描原文即可完成全部命中定位，时间复杂度稳定在 O(n + m + z)，其中 z 是总匹配数。C++ 没有标准库实现，但可轻量手写（200 行内）或用成熟小库如 ahocorasick（header-only，MIT 协议）。
- 构建时所有敏感词必须预编译进状态机，不支持运行时热增删（若需，得加锁+重建，代价高）
- 失败指针必须包含输出链（output link），否则会漏掉“主串中嵌套词”，比如词库含“南京”和“京”，输入“南京路”应同时命中两个
- 掩码替换不能原地修改字符串（避免迭代器失效），推荐用
std::vector<:pair size_t>></:pair>先存所有匹配区间，再倒序替换（防止 offset 偏移）
掩码策略要区分场景：统一掩码 vs 语义保留
纯脱敏（如日志上报）可用固定星号 "***"；但合规场景常要求保留首尾字（如“张*丰”、“138****1234”），这就需要在 AC 匹配回调中记录原始子串，并按规则生成掩码结果。注意：std::string::substr 是 O(k) 拷贝，高频调用会放大开销，建议用 std::string_view 延迟提取。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 手机号：“1[3-9]\d{9}” 这类正则规则，别塞进 AC 词库——AC 只适合精确词，正则用
std::regex单独走一遍（或换re2库） - 中文字符掩码要注意 UTF-8 编码边界，
std::string下直接按 byte 截取会出乱码，必须用utf8cpp或手动解析 Unicode code point - 若需高吞吐（如每秒百万级文本），掩码生成应预分配 buffer，避免反复
reserve和append
实测性能瓶颈往往不在匹配，而在内存与编码
我们压测过 10 万词库 + 1KB 文本：AC 匹配耗时约 3–8μs，但后续字符串拼接+UTF-8 处理占了 70% 以上时间。真正卡点是 std::string 的小字符串优化（SSO）失效、频繁堆分配，以及每次替换引发的内存移动。
立即学习“C++免费学习笔记（深入）”；
- 用
absl::string_view替代std::string_view（如果已引入 Abseil），它对子串切片更友好 - 输出结果用
std::string预分配容量：result.reserve(input.size() + 2 * match_count)（假设每个掩码比原文长 2 字节） - Linux 上启用
malloc_trim(0)防止 jemalloc/tcmalloc 缓存膨胀，尤其长周期服务
AC 自动机本身很稳，但一不留神，UTF-8 解析、内存分配、string 拼接这些“周边操作”就把性能吃光。动手前先用 perf record -g 看一眼热点在哪，别默认“匹配慢”。
