c++oding="utf-8" ?>
不能用std::string::replace循环替换敏感词，因其每次调用触发内存重分配、无法处理重叠匹配与替换后新敏感词，且性能随词量平方级下降；应采用ac自动机构建trie单次扫描匹配，再按end降序合并区间、从后往前构建结果。
敏感词替换为什么不能用 std::string::replace 循环遍历
直接对长文本逐个调用 std::string::replace 查找并替换敏感词，会触发多次内存重分配和子串扫描，时间复杂度接近 O(n×m×k)（n=文本长度，m=敏感词数量，k=平均敏感词长度）。更糟的是，替换后位置偏移会导致漏匹配或重复匹配——比如“比特币”被替成“**币”，后续“币”可能又被误判为独立敏感词。
实操建议：
- 改用单次扫描 + 多模式匹配，避免反复遍历原文本
- 优先构建
AC automaton（Aho-Corasick）或trie+ KMP 回退，把敏感词集合预处理成状态机 - 若敏感词极少（≤10 个）且长度固定，可用
std::string_view配合find_first_of+ 手动滑动窗口，但需自行维护当前偏移
如何用 AC automaton 实现零拷贝掩码标记
AC 自动机本质是带失败指针的 trie，支持在一次文本扫描中同时匹配所有敏感词。关键不是“替换”，而是“定位”——拿到每个匹配的起始/结束下标后，再批量写掩码字符（如 *），避免边匹配边修改字符串引发迭代器失效。
实操建议：
- 使用开源轻量实现（如
ac_string_matcher或自己封装std::vector<:array>></:array>的 trie 节点），避免依赖 heavy 库 - 匹配结果存入
std::vector<:pair size_t>></:pair>，按起始位置排序后合并重叠区间（如“比特币”和“币”同时命中时，合并为 [0,4) 而非两段） - 最后用
std::fill或memset对原始std::string的指定区间赋值掩码，比反复substr+insert快 3–5 倍
std::regex 在敏感词脱敏中为何通常不推荐
std::regex 编译开销大，且默认不支持部分匹配（partial match）——它会尝试全局回溯，遇到“.*比特币.*”这类通配规则极易触发灾难性回溯；C++17 的 std::regex_iterator 也无法保证匹配顺序与文本顺序一致，导致掩码位置错乱。
实操建议：
- 仅当敏感词含简单通配（如“比*币”）且总数 std::regex_replace，但必须加超时保护（无法直接设 timeout，需用
std::chrono包裹并提前中断） - 永远不要用
.*开头的 pattern；改用字面量拼接：将“比[特|特]币”拆成多个确定 pattern 分别编译 - 注意
std::regex在 libstdc++ 和 libc++ 中行为差异：前者不支持\uUnicode 转义，后者对中文支持更好但构造慢
性能临界点：什么时候该切到 mmap + SIMD 加速
当单次脱敏文本 > 1MB 或敏感词库 > 1000 条时，纯 CPU 状态机已逼近瓶颈。此时应放弃逐字节扫描，改用 memchr 定位首字符候选位置，再用 memcmp 或 AVX2 _mm256_cmpeq_epi8 并行比对固定长度敏感词。
实操建议：
- 先按敏感词首字节分组（如哈希到 256 个桶），减少无效比对次数
- 对长度 ≤ 16 的敏感词启用 SSE4.2
_mm_cmpestrm，实测比循环快 2.3×；但需确保输入地址 16 字节对齐 - Linux 下可
mmap敏感词文件只读映射，避免std::vector<:string></:string>的堆碎片；Windows 则用VirtualAlloc+MEM_COMMIT
真正难的不是写对一个替换函数，而是判断当前业务里敏感词是否动态加载、是否需要支持模糊匹配（如“比特*”）、以及掩码后是否还要保留原始语义结构（比如 JSON 字段名不能动）。这些需求一叠加，AC 自动机就得改造成带 payload 的变体，而不再是个教科书例子。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
