应将敏感词过滤逻辑下沉至字节/字符读取环节，通过自定义Reader在解码过程中边解析边清洗，结合Trie树流式匹配与编码错误处理器机制，实现低内存、高吞吐、字符边界对齐的实时过滤。
直接在转换流中嵌入敏感词或非法字符过滤，关键不是“先转码再过滤”，而是把过滤逻辑下沉到字节/字符读取环节——即在解码过程中边解析边清洗，避免全量加载、减少内存占用、保持流式吞吐。
用自定义 Reader 封装过滤逻辑（Go / Java / Python 均适用）
不依赖中间字符串拼接，而是在 Read() 或 read() 方法里逐块处理原始字节流：
- 对输入流（如
*os.File或InputStream）做一层包装，内部维护扫描状态（例如当前是否在注释块、是否刚读到某个前缀） - 每次调用
Read(p []byte)时，从源流读入原始字节 → 解码为 rune 或 String（按需指定编码，如 UTF-8）→ 执行敏感词匹配或非法字符校验 → 写入目标缓冲区 - 遇到敏感词可替换为
***，遇到非法 UTF-8 字节序列可按策略跳过（ignore）、替换成 （replace），或提前终止（strict） - 示例场景：读取 12GB 日志文件导入数据库前，实时剔除含“密码”“token”的行，且不产生临时大字符串
在字符解码阶段注入过滤器（推荐 Java & Python）
利用语言提供的解码错误处理器机制，在从字节转字符时同步干预：
- Java 中通过
CharsetDecoder的onUnmappableCharacter()+ 自定义Callback：当某段字节无法映射到目标编码（如 GBK 里没有的生僻字），不直接丢弃，而是先查敏感词表，命中则返回掩码，否则走默认替换 - Python 中使用
codecs.register_error注册自定义错误处理函数：例如定义def replace_sensitive(ex): ...，在decode('gbk', errors='replace_sensitive')被触发时，提取出错位置附近的上下文，执行 DFA 敏感词扫描 - 优势：复用标准解码流程，不破坏流结构；错误点即清洗点，天然对齐字符边界
结合前缀树（Trie）做流式敏感词匹配
避免正则或多次 str.replace() 带来的重复扫描开销，适合高吞吐文本流：
- 预加载敏感词构建 Trie 树（支持单字节/Unicode 混合），每个节点记录是否为终结词、词长度、替换标记
- 在 Reader 的读取循环中，维护一个滑动窗口 buffer（如 512 字节），按字符推进指针，同步在 Trie 中状态转移
- 一旦匹配成功，立即截断当前 chunk、插入掩码、重置匹配状态；未匹配则原样输出
- 比 AC 自动机更轻量，无状态回溯开销，适合嵌入 I/O 管道底层
注意源头与边界：别让过滤变成掩耳盗铃
很多“过滤失效”其实源于数据源头失控：
- 确认输入流真实编码，不要把 GBK 当 UTF-8 解码——否则敏感词根本无法正确识别（比如“政”在 GBK 是双字节
0xC8\xFE，UTF-8 解作三个乱码字） - 对换行符、BOM、零宽空格等隐形字符做预清理，它们可能干扰 Trie 匹配或绕过正则边界（
\b） - 日志中记录被过滤项的原始字节偏移和上下文（如前后 10 字符），便于审计与规则迭代
- 避免在过滤后二次编码——例如先 UTF-8 decode → 过滤 → GBK encode，若中间用了
ignore，会丢失原始字节线索
