AC自动机是唯一满足极速匹配、零漏替、低内存的敏感词脱敏方案；std::string::find+replace因O(n×m)复杂度、重叠词处理失败、UTF-8截断等问题必然导致性能崩溃与结果错误。
直接用 std::string::replace 或嵌套 find 做敏感词脱敏，性能必然崩——不是调优能救的，是算法层就错了。AC 自动机（Aho-Corasick）是唯一能同时满足「极速匹配」「零漏替」「低内存」三要素的方案，其他路径要么卡顿、要么越界、要么爆内存。
为什么 std::string::find + replace 一定会拖垮服务
常见错误现象：for (auto& w : words) s.replace(s.find(w), w.size(), "***") 看似简单，实则灾难：文本每扫一次就要重头找一遍，1000 个词 × 1KB 文本，实测耗时常超 10ms；“北京”和“北京市”共存时，先替“北京”会把后缀切碎，导致“北京市”永远匹配不到；“张三丰”里“张三”和“三丰”重叠，暴力替换后变成“**丰”，而非“***”。
- 时间复杂度是
O(n × m)，n是文本长度，m是词表大小，不随业务增长而收敛 - 每次
replace都触发内存 realloc，长文本下拷贝开销爆炸 -
std::string按字节操作，中文 UTF-8 字符被截断成乱码（如s[3]落在“你”字中间） - 无法处理“最长前缀优先”或“多词同位置命中”，输出不可控
AC 自动机必须这样初始化才不出错
构建阶段出错，后面全白忙。90% 的线上故障源于失败指针没建好，或敏感词没归一化。
- 插入前必须去重：
std::unordered_set<:string></:string>过滤重复项，空字符串直接跳过 - 按长度升序插入：短词（如“色”）要先于长词（如“色情”）进 Trie，否则 fail 指针无法指向正确输出
- UTF-8 文本必须做码点级对齐：别用
char建节点，改用uint8_t或统一转std::u32string后再建树 - 构建完成后立即调用
build_failure_links()，别懒、别延迟到第一次search时再算 - 回调中必须绑定
tag_id：ac.insert(word.c_str(), word.length(), tag_id)，避免后续查掩码策略时无依据
掩码替换必须倒序合并区间，否则索引全乱
拿到一堆 {start, length} 匹配结果后，直接从左往右替换会因字符串变长/变短导致后续坐标偏移——这是最常踩的坑。
立即学习“C++免费学习笔记（深入）”；
- 先用
std::vector<:pair size_t>></:pair>存所有{start, end}（注意是字节偏移） - 按
end降序排序：std::sort(matches.rbegin(), matches.rend())，确保右边替换不影响左边 - 合并重叠区间：
next.start 就合并，避免“张三”和“三丰”在“张三丰”中分两次替换 - 预分配结果串：
result.reserve(input.size() + 2 * matches.size())，防止多次 realloc - 掩码字符数必须严格等于原词字节数：
std::string(len, '*')，别硬写"***"——中文“宝”占 3 字节，就得填 3 个*
真正压测过的低内存关键点
实测 10 万词库 + 1KB 文本，AC 匹配仅耗 3–8μs，但后续拼接若没控制住，内存分配开销能翻 5 倍。
- 禁用
std::string::substr在循环里高频调用——它是O(k)拷贝，改用std::string_view延迟提取 - 不要用
result += segment拼接，改用std::copy写入预分配 buffer - 若需保留首尾字（如“张*丰”），在 AC 回调中只记录
{pos, len, tag_id}，掩码生成延后统一做 - 手机号、身份证等正则规则别塞进 AC 词库——AC 只适合精确词，
std::regex单独走一遍，或换re2库防回溯 DoS - HTML 标签跳过不用完整解析器，用状态机区分 “标签内”、“URL 内”、“普通文本” 三类区域，只对后者调 AC
最易被忽略的是：AC 匹配返回的是字节偏移，但掩码策略依赖 Unicode 码点数（比如“张*丰”要保留首尾字符，不是首尾字节）。UTF-8 场景下，必须用 utf8cpp::distance 或手动解析，把字节区间映射回码点位置——跳过这步，所有语义掩码都不可靠。
