dfa比正则更适合敏感词脱敏因其一次构建、多次复用，匹配为纯状态跳转，时间复杂度o(n)，不随词库规模恶化；而正则在词量大时编译开销高、匹配需回溯，易漏匹配或性能骤降。
为什么 DFA 比正则匹配更适合敏感词脱敏
因为正则在敏感词量稍大（比如超 500 条）时，Pattern.compile() 开销陡增，且每次 matcher.find() 都要回溯扫描全文；DFA 一次构建、多次复用，匹配是纯状态跳转，时间复杂度接近 O(n)（n 是文本长度），不随词库规模线性恶化。
常见错误现象：用 String.replaceAll() 配合一堆 Pattern 实例做多轮替换，结果吞吐掉一半，CPU 跑满，还漏掉“北京”被“京”提前截断这类嵌套词。
- 敏感词必须预加载进内存，不能边查 DB 边匹配 —— 否则 DFA 失去意义
- 词库更新需重建整个
TrieNode树，不适合秒级热更场景 - 中文需注意全角/半角、大小写、空格干扰，DFA 默认不处理，得前置 normalize（如统一转小写、去空格）
如何用 Java 构建最小可用的 DFA Trie 树
核心就两个类：TrieNode（带 isEnd 和 next Map）和 DfaFilter（含 build() 和 filter()）。别一上来就抄开源库，先手写清楚状态流转逻辑。
关键点在于：每个 TrieNode 的 next 键必须是 char（不是 String），否则无法支持单字匹配（如“炸”“弹”“炸药”共用“炸”节点）；终止节点要存原始词（word 字段），方便后续替换或审计。
- 构建时逐字符插入，遇到已有分支就复用，末尾设
isEnd = true并存word - 不要用
HashMap<character trienode></character>存next—— 中文字符范围大，哈希冲突多；改用ObjectArray或TreeMap更稳（小词库直接HashMap也行） - 避免在
filter()过程中反复 new StringBuilder —— 复用ThreadLocal<stringbuilder></stringbuilder>或传入 buffer 参数
// 示例：插入“比特币”后，树结构为 '比'→'特'→'币'（isEnd=true, word="比特币"） // 若再插“比特”，则 '比'→'特' 节点 isEnd=true, word="比特"
匹配时怎么避免“北京”被“京”吃掉或漏掉长词
标准 DFA 匹配默认是“最短匹配”（遇到 isEnd 就停），但脱敏要求“最长匹配”——“北京欢迎你”里，“北京”优先于“京”。必须在匹配循环里持续记录最近一次 isEnd 位置，并等到无法延伸时才提交。
典型错误：写成“见 end 就替”，导致“北京”被拆成“北”+“京”两段替换，或者“北京欢迎你”只替了“北京”，漏掉更长的“北京欢迎你”（如果词库里真有这个词）。
- 匹配指针
i不回退，但用endPos和matchedWord缓存当前最长有效词 - 每步都检查当前节点是否
isEnd，是则更新缓存；继续走下一步，直到next为空或字符不匹配 - 确认匹配结束（非因失配中断）才执行替换，否则清空缓存继续
- 若词库含“北京”和“北京市”，必须保证后者优先 —— 插入顺序无关，靠匹配过程中的最长路径决定
生产环境要注意的三个隐形坑
本地跑通不等于上线安全。实际压测常暴露三类问题：内存泄漏、线程不安全、替换污染。
-
DfaFilter实例必须单例复用，别每次请求 new 一个 ——TrieNode树对象图很大，GC 压力直线上升 - 构建树的
build()方法不是线程安全的，必须在启动时完成，运行期禁止并发调用；热更新需加双检锁 + volatile 引用替换 - 替换逻辑若用
String.replace()回填，可能把已脱敏的“**”再次当原文扫描 —— 必须用索引偏移原地拼接，或确保替换后跳过已处理区域
最易被忽略的是：DFA 对“零宽断言”“模糊匹配”完全无能为力。比如“比特*”“比?特”这种通配需求，得切回正则，别硬塞进 Trie。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
