不能直接用 strings.replaceall 处理大文件，因会将整个文件加载到内存并多次拷贝字符串，gc压力大且需重复扫描；应采用流式处理结合 ahocorasick 多模式匹配算法，预加载敏感词构建自动机，按行或分块读取并精准替换。
为什么不能直接用 strings.ReplaceAll 处理大文件
因为内存会爆。读取一个 500MB 的日志文件到内存，再对每个敏感词调用 strings.ReplaceAll，不仅 GC 压力大，还会触发多次字符串拷贝——Go 中字符串是只读的，每次替换都生成新副本。更糟的是，如果敏感词有几百个，就得扫文件几百遍。
真正可行的路只有一条：流式处理 + 多模式匹配算法。别想着“先加载再处理”，得边读边筛。
用 ahocorasick 库做流式敏感词匹配
Go 生态里最靠谱的多模式匹配库是 BobuSumisu/ahocorasick（不是标准库，但维护活跃、无 CGO、支持 Unicode）。它把所有敏感词构建成自动机，一次扫描就能命中多个词，时间复杂度接近 O(n)，和敏感词数量无关。
实操要点：
- 敏感词必须预加载进
ahocorasick.NewTrie()，不能边读边加（否则重建开销大） - 用
bufio.Scanner按行读，但注意：跨行敏感词（比如“违\n法”）会被漏掉；若需支持，得改用bufio.NewReader+ 自定义分块（如每次读 64KB，保留末尾 100 字节作重叠缓冲） - 匹配结果返回的是
start和end字节位置，不是 rune 位置——遇到中文或 emoji 时，别直接用str[i:j]切，先转成[]rune再算索引，或用utf8.DecodeRuneInString定位
替换策略要分场景选：mask 还是 remove 还是 reject
不同业务对“过滤”的定义完全不同：
- 日志脱敏（如审计系统）：常用星号掩码，
replaceFunc里用strings.Repeat("*", utf8.RuneCountInString(match))，注意别用len(match)——那只是字节数 - 用户评论审核：发现任一敏感词就整条拒绝，这时不用替换，只需
trie.FindAllWordIndexes(line)判非空即可中断 - 搜索引擎屏蔽：需保留上下文，只高亮不删，可把匹配段包上
<span class="blocked">xxx</span>，但输出前要 HTML 转义防 XSS
别在匹配后用 strings.Replace 全局扫一遍——又回到 O(n×m) 了。应该用 bytes.Buffer 配合匹配结果做单次拼接：
buf := &bytes.Buffer{}
last := 0
for _, m := range matches {
buf.WriteString(line[last:m.Start])
buf.WriteString("***")
last = m.End
}
buf.WriteString(line[last:])
性能瓶颈往往卡在 I/O 和编码上
实测发现，90% 的耗时不在匹配本身，而在：
- 没设
bufio.NewReader(f).ReadSize = 1<em>1024</em>1024（默认 4KB，小缓冲导致系统调用太频繁） - 文件是 GBK 或 Big5 编码，却用
os.Open直读——Go 默认按 UTF-8 解析，中文全变，匹配失效。必须用golang.org/x/text/encoding先解码，再喂给 Trie - 敏感词表含大量形近词（如“发财”带零宽空格），而输入文本没 normalize。建议预处理词表：用
unicode.NFC.String()归一化，再建 Trie
真正上线前，拿真实语料跑 go tool pprof 看火焰图——十有八九热点在 runtime.mallocgc 或 io.ReadAtLeast，而不是 ahocorasick 里。
