DFA比正则匹配更适合敏感词过滤，因其将所有词构建成状态转移图，文本仅扫描一遍，时间复杂度接近O(n)，且词库规模扩大时过滤性能稳定；而正则逐条匹配在词库达数百个时性能显著下降。
为什么 DFA 比正则匹配更适合敏感词过滤
正则 Pattern.compile() 逐条匹配敏感词，词库一到几百个，性能就明显下滑；DFA 把所有词构建成一张状态转移图，文本只扫描一遍，时间复杂度接近 O(n)。关键不是“多快”，而是“稳定”——词库从 100 扩到 10000，DFA 建树慢一点，但过滤耗时几乎不变。
常见错误现象：String.contains() 硬扫、replaceAll() 配合动态拼接正则（如 "(?i)" + word），词多时 CPU 持续飙高，甚至触发 GC 频繁停顿。
- DFA 不适合做模糊匹配（比如拼音替换、形近字），它认的是严格字符序列
- 建树阶段必须去重、剔除包含关系（如“苹果”和“苹果手机”，后者可删），否则状态节点冗余，内存涨得快
- 中文需注意全角/半角、大小写——DFA 默认区分，通常要预处理统一转小写+半角
用 Java 实现基础 DFA 节点结构的关键点
核心是 Node 类：每个节点存一个 Map<character node></character> 表示子节点，加一个布尔字段 isEnd 标记是否为词尾。别用 HashMap 直接存 char，中文字符范围大，推荐用 ConcurrentHashMap<character node></character> 或更省内存的 ObjectArray（但得自己 handle null）。
容易踩的坑：Node 的 children Map 如果用 new HashMap()，并发构建时可能出错；如果用 Collections.synchronizedMap()，又锁太重。实际项目里，建议先单线程建树，再并发读取。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 不要在
Node里存原始词字符串（如word字段），浪费内存；需要时靠路径回溯或建树时在isEnd处存wordId - 避免递归建树，用 while 循环 + 当前节点引用，防止超长词（比如 50 字）导致栈溢出
- 词库含 emoji 或生僻汉字时，确保 JVM 启动参数含
-Dfile.encoding=UTF-8，否则char拆分可能错位
敏感词替换时怎么保留原格式（比如星号长度匹配汉字数）
直接用固定 "***" 替换会暴露词长，也难看。正确做法是在 DFA 匹配到终点后，根据匹配起始/结束下标，按原字符数生成掩码：中文、emoji 算 1 个，ASCII 字母数字算 1 个，但显示时统一用 * 或 •。
示例逻辑片段：
int start = matchStart;
int end = matchEnd;
StringBuilder mask = new StringBuilder();
for (int i = start; i < end; i++) {
char c = text.charAt(i);
mask.append(c >= 0x4e00 && c <= 0x9fff ? "•" : "*"); // 中文区用•，其余用*
}
- 别用
String.replaceAll()做多次替换，它内部反复 copy 字符串，大文本下 GC 压力大 - 如果要求“高亮不替换”，只需记录所有
[start, end)区间，交给前端渲染，后端不拼接新字符串 - 注意索引越界：文本含
、u200b 零宽空格时，
charAt()下标和视觉位置可能错位，预处理建议先text.replaceAll("\p{Cf}", "")清理格式字符
上线前必须验证的三个边界场景
很多 DFA 实现本地跑得通，一上生产就漏词或卡死，问题往往出在没压测真实语料。
- 超长文本（>10MB）：别用
String加载，改用InputStreamReader分块读，每次喂 8KB 左右进 DFA 扫描器 - 嵌套词：“王八蛋”和“蛋炒饭”共存时，DFA 必须支持“最长匹配”或“最短匹配”策略可配，否则“王八蛋炒饭”可能只标出“王八蛋”，漏掉“蛋”开头的另一条路径
- 热更新词库：不要每次 reload 全量重建 DFA 树（停服风险），用双缓冲机制——新树构建完，原子替换引用，旧树等当前请求结束后再 GC
真正麻烦的不是算法本身，是词库质量、编码一致性、还有替换后要不要做二次语义校验。这些没法靠 DFA 一步到位，得在它外面包一层业务逻辑。
