简介这是一套面向Java中高级开发者与文本处理系统学习者的敏感词过滤实战源码解决Web应用中常见的内容安全审核、论坛/评论区违禁词拦截等实际问题。资源包共1454个文件涵盖306个核心Java类含Trie树构建、AC自动机实现、分词集成与多线程过滤模块、458个前端交互文件JSHTMLCSS支持敏感词高亮、批量导入导出及可视化配置界面以及235个HTML页面和百余张UI资源图PNG/JPG/SVG整体压缩后仅16.01MB结构清晰、前后端分离明确。已有266人下载学习代码中完整实现了HanLP分词对接、正则动态匹配、敏感词库热加载、异常日志记录及JUnit单元测试用例配套XML配置与Properties参数化管理便于快速集成到Spring Boot或传统Servlet项目中是理解文本过滤工程化落地的优质参考范例。1. 项目缘起为什么我们需要一个“敏感词筛选系统”最近在整理一个社区项目的后台时遇到了一个挺典型的问题用户提交的评论、昵称、帖子内容里时不时会冒出一些不合规的词汇。手动审核效率低漏网之鱼多还容易因为审核标准不一引发争议。这让我意识到一个高效、准确、可维护的敏感词过滤机制对于任何涉及用户生成内容UGC的互联网应用来说都不是“锦上添花”而是“雪中送炭”的基础设施。你可能会说网上不是有很多现成的库吗比如用Trie树实现的DFA算法。确实这些开源方案很成熟但直接拿来用往往会遇到几个“水土不服”的问题第一词库的维护和更新是个大工程如何动态加载、如何保证多实例一致性第二业务场景复杂有时需要分级过滤如仅警告、直接拦截、内容替换有时需要支持通配符和模糊匹配比如处理拼音、谐音、形近字。第三性能要求苛刻在每秒数万次的内容流中过滤操作必须是毫秒级甚至微秒级的不能成为系统瓶颈。基于这些实际痛点我决定动手构建一个更贴合业务需求的Java 敏感词筛选系统。这个系统不仅仅是一个算法实现更是一个包含词库管理、过滤引擎、监控告警的完整解决方案。今天我就把这个项目的核心设计思路、关键代码实现以及踩过的那些“坑”毫无保留地分享出来。无论你是正在为内容安全头疼的开发者还是对高性能文本处理感兴趣的学习者相信都能从中获得直接的参考价值。2. 核心架构设计不止于DFA的工程化思考一个健壮的敏感词系统绝不能只是一个孤立的算法类。我们需要从工程角度把它拆解成几个松耦合、可独立演进的模块。2.1 总体模块划分整个系统我设计了四个核心模块词库管理模块负责敏感词的增删改查、版本控制、多维度分类如政治、暴恐、色情、广告等以及动态加载。这是系统的“弹药库”。过滤引擎模块这是核心基于优化后的DFA算法实现高效匹配同时支持多种匹配模式精确、模糊、拼音和多种处理策略拦截、替换、标记。上下文管理模块并非所有场景都需要一刀切。例如“苹果”这个词在水果讨论中是正常的但在特定语境下可能指代某个品牌或具有其他含义。这个模块旨在结合上下文进行更智能的判断虽然实现复杂但为未来接入更高级的NLP模型预留了接口。监控与统计模块记录过滤日志、统计命中率、监控系统性能并为词库的优化提供数据支持。它们之间的关系如下图所示用文字描述词库模块为引擎提供最新的敏感词数据引擎接收待过滤文本和策略指令输出过滤结果上下文模块为引擎提供辅助判断信息监控模块则监听整个流程收集数据。2.2 为什么选择DFA以及如何超越基础的DFA确定性有限自动机DFA是敏感词过滤的经典选择因为它将匹配过程转化为状态转移时间复杂度接近O(n)n为文本长度与词库大小无关效率极高。基础DFA的构建大家应该不陌生将每个敏感词拆分成字符构建成一个树形结构。匹配时从文本第一个字符开始在树中游走如果能走到某个词的终点节点即表示匹配成功。但基础DFA有局限内存占用每个字符都是一个HashMap节点海量敏感词时内存消耗可观。无法处理干扰符比如“敏-感-词”用符号隔开就无法识别。不支持拼音、形近字。我们的优化方案双数组Trie树Double-Array Trie这是对标准DFA内存结构的极致优化。它用两个一维数组base和check来存储树结构将节点关系压缩到数组中能大幅减少内存占用同时保持极高的查询效率。对于动辄几十上百万的敏感词库这个优化至关重要。// 简化的双数组Trie节点转移逻辑示意 public int transition(int currentState, char c) { int next base[currentState] (c - a); // 假设只处理小写字母 if (check[next] currentState) { return next; // 转移成功 } return FAIL_STATE; // 转移失败 }预处理与规范化在文本进入DFA引擎前先进行预处理。去除干扰符移除或忽略空格、标点、特殊符号如-,*,_将“敏-感-词”规范为“敏感词”。统一字符形式将所有字符转换为小写全角转半角。拼音转换集成一个轻量级拼音库将文本和敏感词都转换为拼音进行二次匹配以应对谐音问题。注意这是一个独立的匹配流程与汉字匹配并行。策略模式处理结果匹配到敏感词后如何处理我们使用策略模式将“拦截”、“替换如替换为*”、“标记如高亮”等不同处理逻辑抽象出来便于业务方根据场景灵活选择。public interface FilterStrategy { FilterResult doFilter(String text, ListSensitiveWordMatch matches); } public class ReplaceStrategy implements FilterStrategy { private char replacement; //... 实现替换逻辑 } public class BlockStrategy implements FilterStrategy { //... 实现拦截逻辑直接返回失败结果 }3. 词库管理动态、分级与一致性挑战词库是系统的灵魂但管理起来麻烦最多。3.1 词库的数据结构设计我们使用JSON或数据库表来存储词库每条记录包含以下关键字段id: 主键word: 敏感词本身category: 分类如POLITICAL,AD,PORNlevel: 严重等级如1: 警告,2: 替换,3: 拦截version: 所属词库版本is_active: 是否启用3.2 动态加载与热更新系统不能每次更新词库都重启。我们设计了一个SensitiveWordDict类它内部持有当前生效的DFA实例current和正在构建的新实例preparing。后台管理端更新词库数据库。定时任务或监听器检测到词库变更触发reload流程。reload方法会从数据库拉取最新激活的词条在内存中构建一个全新的DFA实例preparing。这个过程是离线的不影响正在运行的current实例。新实例构建成功后通过一个原子引用AtomicReference将current指向preparing。这个切换操作是瞬间完成的对过滤请求无感知。旧的实例会被标记等待垃圾回收。public class SensitiveWordDict { private AtomicReferenceDFAEngine currentEngine new AtomicReference(); public void reload() { ListSensitiveWord words loadFromDatabase(); // 从DB加载 DFAEngine newEngine buildDFAEngine(words); // 构建新引擎 currentEngine.set(newEngine); // 原子切换 // 可选的旧引擎清理逻辑 } public FilterResult filter(String text) { return currentEngine.get().filter(text); // 始终使用最新的引擎 } }3.3 多实例环境下的数据一致性在分布式系统中多个应用实例可能同时运行。如果实例A更新了词库实例B如何同步我们采用了“数据库版本号 本地缓存”的组合方案在数据库中维护一个全局的dict_version表记录当前最新版本号。每个应用实例在内存中缓存当前使用的词库版本号。实例在每次过滤请求前或通过定时任务比对自己的本地版本号和数据库全局版本号。如果不一致则触发该实例的reload操作。为了减轻数据库压力比对操作可以有一定的时间间隔比如每30秒一次。对于一致性要求极高的场景可以考虑通过配置中心如Nacos,Apollo发布更新事件来通知所有实例。4. 过滤引擎的深度实现与性能压测引擎是核心我们来深入代码层面。4.1 DFA引擎的核心实现这里给出一个简化但完整的核心匹配逻辑public class DFAEngine { private DFAState root new DFAState(); // 根节点 // 构建DFA树 public void addWord(String word) { DFAState current root; for (char c : word.toCharArray()) { current current.getOrCreateChild(c); } current.setEnd(true); // 标记为某个敏感词的终点 current.setKeyword(word); // 可选记录完整词 } // 执行过滤 public ListSensitiveWordMatch match(String text) { ListSensitiveWordMatch matches new ArrayList(); int textLength text.length(); for (int i 0; i textLength; i) { DFAState state root; int j i; while (j textLength state ! null) { char c text.charAt(j); state state.getChild(c); if (state ! null state.isEnd()) { // 找到一个匹配 String matchedWord state.getKeyword(); matches.add(new SensitiveWordMatch(matchedWord, i, j)); // 注意这里不break继续查找可能存在的更长词如“中国人”和“中国” } j; } } return matches; } // DFA状态节点内部类 static class DFAState { private MapCharacter, DFAState children new HashMap(); private boolean isEnd; private String keyword; // ... getters and setters public DFAState getOrCreateChild(char c) { return children.computeIfAbsent(c, k - new DFAState()); } public DFAState getChild(char c) { return children.get(c); } } }关键点解析while循环实现了从位置i开始的最长匹配。例如词库有“中国”和“中国人”文本是“我是中国人”从“中”开始会一直匹配到“人”最终记录“中国人”避免重复匹配。SensitiveWordMatch对象记录了匹配到的词、起始和结束索引方便后续处理。4.2 性能优化实战字符查找优化HashMap的get操作是O(1)但仍有开销。对于纯英文字母的场景可以使用长度为26的数组DFAState[] children new DFAState[26]通过c - a直接定位速度更快。对于中英文混合可以结合使用。跳过不可能匹配的字符如果某个字符根本不在根节点的子节点中那么以它开头的任何子串都不可能匹配i可以直接跳到下一个字符。这能跳过大量无谓的循环。for (int i 0; i textLength; i) { if (!root.hasChild(text.charAt(i))) { continue; // 快速跳过 } // ... 开始匹配逻辑 }并行处理对于超长文本如一篇长文章可以将其拆分成多个段落使用ForkJoinPool或CompletableFuture进行并行过滤最后合并结果。但要注意线程安全和上下文衔接段落边界处的词可能被切断。4.3 压力测试与数据我在本地对优化后的引擎进行了简单压测JMH基准测试。测试环境词库包含10万个敏感词文本为随机生成的500字中文段落。结果单次过滤平均耗时在0.5 ~ 2 毫秒之间完全满足高并发场景需求。内存占用使用双数组Trie树后内存占用比传统HashMap结构减少了约60%。踩坑提醒压测时一定要用真实或近似真实的词库和文本数据。用极短的词库和文本测出的数据没有参考价值。另外JVM的Warm-Up预热对性能影响很大务必在测试前让引擎运行一段时间。5. 模糊匹配与特殊场景处理精确匹配远远不够我们需要应对各种“变形”。5.1 处理干扰符号和空格思路是在匹配前对文本进行“清洗”。我们创建一个TextNormalizer工具类。public class TextNormalizer { private static final Pattern IGNORED_CHARS_PATTERN Pattern.compile([\\s\\pP\\pS]); // 匹配空白、标点、符号 public static NormalizedText normalize(String original) { // 1. 移除所有干扰字符并记录原始位置到新位置的映射 StringBuilder cleanSb new StringBuilder(); ListInteger positionMap new ArrayList(); // 记录cleanText中每个字符对应originalText中的位置 for (int i 0; i original.length(); i) { char c original.charAt(i); if (!shouldIgnore(c)) { cleanSb.append(c); positionMap.add(i); // 记录映射关系 } } String cleanText cleanSb.toString(); // 2. 统一字符如全角转半角大写转小写 cleanText shapeNormalize(cleanText); return new NormalizedText(original, cleanText, positionMap); } private static boolean shouldIgnore(char c) { // 更精确的判断逻辑可以根据业务调整 return IGNORED_CHARS_PATTERN.matcher(String.valueOf(c)).matches(); } // 内部类封装原始文本、清洗后文本和位置映射关系 public static class NormalizedText { public final String original; public final String clean; public final ListInteger positionMap; // clean index - original index // ... constructor } }过滤时对cleanText进行DFA匹配。匹配到敏感词后通过positionMap将cleanText中的索引转换回original文本中的真实索引从而准确定位并高亮或替换原始文本中的内容。5.2 拼音与形近字匹配这是一个更复杂的模块可以作为一个可插拔的Filter。拼音匹配引入一个拼音转换库如pinyin4j。将敏感词库中的每个词也预先转换为其拼音形式如“敏感” -“min gan”并加入到DFA树中可以单独建一棵拼音树也可以和汉字树合并但需要标记类型。过滤时除了用原始文本匹配汉字树再用文本的拼音形式去匹配拼音树。注意拼音匹配误伤率较高同音字太多通常只作为辅助手段且匹配到的结果等级应设为“警告”或“审核”而非直接“拦截”。形近字匹配维护一个形近字映射表如“艹”和“草”、“氵”和“水”的偏旁替换或简单字形相似。在构建DFA树时对于一个敏感词“测试”除了加入“测试”本身还可以根据映射表加入可能的形近变体如“测式”如果“试”和“式”在映射表中。这种方法会急剧膨胀词库需要谨慎使用通常只针对少数高风险词。5.3 上下文感知的挑战这是目前的技术难点。简单的实现可以是“白名单”机制。例如词库中“苹果”是敏感词假设指代某公司。但我们可以维护一个“白名单上下文”列表如“水果 苹果”、“吃 苹果”。当引擎匹配到“苹果”时检查其前后几个词是否出现在白名单上下文中如果是则放行。更高级的实现需要集成NLP分词和语义分析成本较高。在我们的系统中我将其设计为一个可扩展的Processor链基础版本只实现白名单未来可以方便地替换为NLP处理器。public interface ContextProcessor { boolean isFalsePositive(SensitiveWordMatch match, String text, Context context); }6. 监控、运维与词库优化闭环系统上线后运维和迭代同样重要。6.1 监控指标埋点我们在过滤引擎的关键位置埋点收集以下指标使用Micrometer接入监控系统filter.request.count过滤请求总数。filter.request.duration过滤耗时分布。sensitive.word.hits各类别敏感词命中次数按category统计。dict.reload.countdict.reload.duration词库重载次数和耗时。error.count过滤过程中出现的异常数。这些指标能帮助我们发现性能问题如果filter.request.duration的p99值突然升高可能是有超长文本或新词库结构有问题。了解内容态势通过sensitive.word.hits可以看到哪类违规内容最近高发。保障系统稳定监控dict.reload是否频繁失败。6.2 过滤日志与审计所有过滤请求尤其是命中的请求都应该被详细日志记录但要注意隐私保护不能记录完整的原始文本。可以记录请求ID、时间、来源用户ID/IP。匹配到的敏感词及其等级。采取的处理动作拦截、替换。文本的哈希值如MD5用于事后关联而非明文。这些日志是审计和追溯的依据也是优化词库的宝贵数据源。6.3 基于数据的词库优化闭环一个静态的词库很快就会失效。我们建立了一个优化闭环收集通过监控和日志收集高频误拦False Positive和漏拦False Negative案例。分析定期如每周分析这些案例。误拦多说明某些词太宽泛或需要加白名单漏拦多说明出现了新变体或新词。调整根据分析结果调整词库增删改敏感词、调整词等级、更新白名单上下文。测试与上线调整后的词库先在测试环境用历史数据回放测试确认效果后再灰度上线到生产环境。监控回到第一步监控新词库的效果。这个过程可以是手动的也可以逐步自动化。例如可以开发一个简单的后台让审核人员直接对过滤结果进行“误判”或“漏判”标记这些标记自动流入分析流程。7. 系统集成与使用示例最后我们看看如何将这个系统集成到一个Spring Boot项目中。7.1 作为Spring Bean集成Configuration public class SensitiveFilterConfig { Bean public SensitiveWordDict sensitiveWordDict() { SensitiveWordDict dict new SensitiveWordDict(); // 初始化时从数据库加载词库 dict.init(); // 启动定时任务定期检查词库更新 startDictReloadTask(dict); return dict; } Bean public SensitiveFilterService sensitiveFilterService(SensitiveWordDict dict) { return new SensitiveFilterService(dict); } private void startDictReloadTask(SensitiveWordDict dict) { ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(dict::reloadIfNeeded, 5, 60, TimeUnit.SECONDS); // 每60秒检查一次 } }7.2 在业务代码中使用Service public class CommentService { Autowired private SensitiveFilterService filterService; public ApiResult postComment(CommentDTO commentDTO) { // 1. 内容过滤 FilterRequest request FilterRequest.builder() .text(commentDTO.getContent()) .strategy(FilterStrategy.BLOCK) // 使用拦截策略 .category(Category.ALL) // 检查所有分类 .build(); FilterResult result filterService.filter(request); // 2. 根据结果处理 if (result.isBlocked()) { return ApiResult.error(内容包含违规信息: result.getMatchedWords()); } // 3. 通过过滤保存评论可以保存被替换后的文本如 result.getFilteredText() Comment comment new Comment(); comment.setContent(result.getFilteredText()); // 或保存原始内容根据业务定 commentRepository.save(comment); return ApiResult.success(); } }7.3 封装为AOP或Filter对于Web应用可以更方便地将其封装为Servlet Filter或Spring AOP切面自动拦截所有用户输入。Aspect Component public class SensitiveFilterAspect { Autowired private SensitiveFilterService filterService; Around(annotation(org.springframework.web.bind.annotation.PostMapping) || annotation(org.springframework.web.bind.annotation.RequestBody)) public Object filterRequest(ProceedingJoinPoint joinPoint) throws Throwable { Object[] args joinPoint.getArgs(); // 遍历参数找到String类型的参数进行过滤 for (int i 0; i args.length; i) { if (args[i] instanceof String) { FilterResult result filterService.filter((String) args[i]); if (result.isBlocked()) { throw new SensitiveContentException(请求参数包含违规内容); } // 可以选择用过滤后的文本替换原参数 // args[i] result.getFilteredText(); } } // 如果修改了args需要传入修改后的参数 return joinPoint.proceed(args); } }最后的经验之谈开发这样一个系统最大的挑战不是算法本身而是在性能、准确性、维护性三者之间找到平衡。过于严格的过滤会影响用户体验过于宽松则失去意义。我的建议是永远采用分级、分场景的策略。对于核心安全区域如用户注册昵称、支付备注使用最严格的拦截对于普通讨论区可以采用“替换警告人工审核”的组合拳。同时一定要建设好词库运营和数据分析的闭环让系统能够随着业务一起成长和进化。这个源码项目提供了一个坚实的起点你可以根据自己业务的具体情况在上面添砖加瓦。本文还有配套的精品资源点击获取