如何实现ThinkPHP的敏感词过滤系统_DFA算法字典树在评论模块中的应用-ThinkPHP-PHP中文网

DFA比正则更适合敏感词过滤，因其建树一次、匹配O(n)，词库增大不降速；而正则性能断崖下降，strpos循环或str_replace易误伤漏判。

如何实现thinkphp的敏感词过滤系统_dfa算法字典树在评论模块中的应用

因为正则在词库变大后性能断崖式下降，而 DFA 是一次性建树、多次 O(n) 匹配（n 是文本长度），对高频短文本（如评论）更稳。尤其当你的敏感词库超过 500 条，preg_match_all 可能卡住请求，而 DFA 查找不随词量线性增长。

常见错误现象：strpos 循环遍历词库 → 每条评论都要扫几百次字符串；或用 str_replace 全局替换 → 误伤“和谐”里的“和”，漏掉“河蟹”这种变形词。

不用引入第三方包，核心就两个类：一个构建树（DfaTreeBuilder），一个执行匹配（DfaFilter）。关键不是代码多，而是节点存储方式 —— 必须用索引数组而非对象，否则 PHP-FPM 下每次请求重建对象开销太大。

实操建议：

把敏感词列表存在数据库表 sensitive_words，字段 word 和 status（启用/禁用），启动时用 Db::table('sensitive_words')->where('status', 1)->column('word') 加载
构建树时，每个节点用 ['is_end' => true, 'next' => []] 表示，next 的 key 是 UTF-8 单字符（用 mb_substr($char, 0, 1, 'utf-8') 安全截取）
避免递归建树，改用循环，防止超长词触发 max_execution_time 或栈溢出
缓存树结构到 runtime/cache/dfa_tree.php，用 var_export 写入，下次直接 require，比 JSON 解析快 3 倍

别在控制器里临时 new 一遍树，也别把树塞进 Session —— 它是只读静态结构，应该作为单例由容器管理。ThinkPHP 6+ 推荐绑定到 app/provider.php：

return [
    \app\common\service\DfaFilter::class => \think\Container::getInstance()->get(\app\common\service\DfaFilter::class),
];

使用场景中容易踩的坑：

DfaFilter::check($content) 返回命中的词列表，但默认不返回位置 —— 如果要高亮或截断，得改写匹配逻辑，记录起始 offset
遇到“未成年”和“未成年上网”，后者会先命中前者，导致后半截“上网”被忽略 → 必须开启最长匹配模式（遍历时持续更新 $matched，不一匹配就跳出）
用户输入“ni ma”带零宽空格，DFA 默认过不了 → 预处理阶段要加 preg_replace('/\s+/u', '', $text) 清除不可见空白符
ThinkPHP 的 input('post.content') 可能已做过 trim 或 htmlspecialchars，注意过滤顺序：先还原 HTML 实体（htmlspecialchars_decode），再走 DFA，最后入库前再转义

树一旦生成就固定，数据库新增词不会自动进树。很多人以为改了数据库就能立刻生效，结果测试时一直不拦截新词。

解决方案只有两个方向：

运维侧：加个后台按钮，点击后执行命令 php think dfa:build，重新 dump 树文件并 touch 更新时间戳；Nginx 配置监听该文件 mtime，变化后 reload worker
开发侧：在 DfaFilter 构造函数里加检查，如果 filemtime(cache_path) ，就强制重建（仅限低频站点，慎用）
绝对不要用 opcache_invalidate 强刷缓存文件 —— 它在 CLI 模式下无效，且可能引发并发重建冲突

最常被忽略的一点：DFA 对大小写、全半角、简繁体完全敏感。要支持“微软”和“微軟”，得在入库时统一转简体+小写，而不是靠树来兼容 —— 树只做精确匹配，语义归一化必须前置。