敏感词过滤看起来是个简单需求：把词存起来，文本来了逐个比对就行。但当词库规模达到几万条、请求量上来之后，暴力遍历的性能会迅速崩塌。本文以SQLite作为词库存储，结合DFA匹配算法，完整走一遍从表结构设计、词库维护到匹配引擎实现的全过程，并给出实际压测数据和踩坑经验。
为什么选择SQLite做敏感词词库
敏感词词库的特点是读多写少、数据量中等（通常几千到几十万条）、对事务一致性有一定要求。MySQL当然可以做，但对于嵌入式设备、单机服务、桌面工具这类场景，引入一个独立的数据库服务显得过重。SQLite是一个嵌入式的文件型数据库，零部署、零配置，整个词库就是一个文件，随应用分发即可，非常适合词库这种结构化数据。
另一个关键优势是事务支持。词库更新往往不是单条操作，而是批量导入、批量删除，例如运营一次性上传一份新增词表。SQLite在事务内执行批量写入的性能非常可观，合理使用事务可以把十万条数据的写入压缩到秒级。如果逐条提交，性能会差几个数量级，这一点后面会专门讲。
此外，SQLite的WAL模式允许读写并发，词库热更新时不会长时间阻塞查询进程，这对在线服务的平滑更新很有价值。
词库表结构设计与索引优化
一张合格的敏感词表至少要包含词本身、分类、级别和状态字段。分类用于区分政治、色情、广告等不同类型，级别决定命中后的处理策略（替换、拦截还是人工审核），状态字段支持软删除，方便回滚误操作。
CREATE TABLE IF NOT EXISTS sensitive_word (
id INTEGER PRIMARY KEY AUTOINCREMENT,
word TEXT NOT NULL,
category TEXT NOT NULL DEFAULT 'general',
level INTEGER NOT NULL DEFAULT 1,
status INTEGER NOT NULL DEFAULT 1,
created_at TEXT NOT NULL DEFAULT (datetime('now','localtime'))
);
CREATE UNIQUE INDEX IF NOT EXISTS uk_word ON sensitive_word(word);
CREATE INDEX IF NOT EXISTS idx_status ON sensitive_word(status);
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;这里有两个容易忽视的点。第一，word字段必须建唯一索引，它既保证幂等导入（重复词不会重复插入，配合INSERT OR IGNORE直接跳过），又是查询加速的基础。第二，启动时打开WAL模式和调整synchronous参数，能显著降低写放大带来的等待。注意SQLite默认每条语句都是独立事务，批量导入时务必显式开启事务。
BEGIN; INSERT OR IGNORE INTO sensitive_word(word, category, level) SELECT '敏感词示例', 'politics', 3 WHERE NOT EXISTS (SELECT 1 FROM sensitive_word WHERE word = '敏感词示例'); COMMIT;
用DFA算法实现毫秒级匹配
有了词库，下一步是匹配引擎。朴素做法是对每个敏感词调用字符串查找，时间复杂度是词数乘以文本长度的乘积级别，五万词的词库处理一篇千字文章要做五万次扫描。DFA（确定有限自动机）把所有词编译成一棵树形状态机，匹配时只需沿文本逐字符走一遍，复杂度与文本长度成正比，与词库规模基本无关。
典型流程是：服务启动时从SQLite加载所有有效词，构建DFA树；匹配时从头遍历文本每个字符，沿树下降，命中终止节点即报告敏感词。下面是Java版本的核心实现。
public class DfaFilter {
private final Map<Character, Object> root = new HashMap<>();
private static final char END = 0;
// 从词表构建DFA树
public void loadWords(List<String> words) {
for (String word : words) {
Map<Character, Object> node = root;
for (char c : word.toCharArray()) {
node = (Map<Character, Object>)
node.computeIfAbsent(c, k -> new HashMap<Character, Object>());
}
node.put(END, END); // 标记词结束
}
}
// 返回文本中命中的所有敏感词
public Set<String> match(String text) {
Set<String> hits = new HashSet<>();
for (int i = 0; i < text.length(); i++) {
Map<Character, Object> node = root;
StringBuilder sb = new StringBuilder();
for (int j = i; j < text.length(); j++) {
char c = text.charAt(j);
Object next = node.get(c);
if (next == null) break;
node = (Map<Character, Object>) next;
sb.append(c);
if (node.containsKey(END)) hits.add(sb.toString());
}
}
return hits;
}
}实际使用中还需要处理变体规避问题。用户会用拼音、同音字、符号穿插（比如把两个字中间插一个星号）来绕过过滤。常见对策是匹配前先做文本归一化：全角转半角、转小写、剔除空白和常见干扰符号，再对归一化后的文本做DFA匹配，命中后映射回原文位置进行替换。
词库热更新与性能压测
词库不是一成不变的，运营随时会增删词条。由于DFA在内存中，直接改数据库不会让运行中的匹配引擎感知变化。推荐的做法是版本号加双缓冲：词库表加一张meta表记录当前版本，更新服务改完数据后递增版本号；业务进程定时（或通过消息通知）检查版本，发现变化就重新加载词表，在后台线程构建新DFA树，构建完成后用引用替换旧树。整个过程无锁读、原子切换，不会出现匹配到一半的中间状态。
public class FilterHolder {
private volatile DfaFilter current = new DfaFilter();
public void reload(List<String> words) {
DfaFilter next = new DfaFilter();
next.loadWords(words); // 后台构建，不影响线上
current = next; // 原子引用替换
}
public Set<String> check(String text) {
return current.match(text);
}
}压测方面，笔者在一台普通四核笔记本上验证过：五万词规模的DFA树构建耗时约300毫秒，单次千字文本匹配耗时不到0.1毫秒，QPS轻松达到数十万。对比暴力遍历的方案，同样数据量下单次匹配需要十几毫秒，差距在百倍以上。内存方面，五万词的HashMap树大约占用几十MB，大多数场景完全可以接受；如果词库达到百万级，可以考虑换用双数组Trie压缩内存。
最后总结几条实践建议：批量写入务必包在事务里；加载词库时只查status为有效的记录并配合索引；文本先归一化再匹配；热更新用引用替换而非加锁。按这套方案落地，SQLite加DFA的组合足以支撑绝大多数中小规模系统的内容安全需求，而且整个方案零外部依赖，部署维护成本几乎为零。