DFA比正则更适合敏感词过滤，因其建树一次、匹配O(n)，词库增大不降速；而正则性能断崖下降，strpos循环或str_replace易误伤漏判。
为什么 DFA 比正则匹配更适合评论敏感词过滤
因为正则在词库变大后性能断崖式下降，而 DFA 是一次性建树、多次 O(n) 匹配（n 是文本长度），对高频短文本（如评论）更稳。尤其当你的敏感词库超过 500 条，preg_match_all 可能卡住请求，而 DFA 查找不随词量线性增长。
常见错误现象：strpos 循环遍历词库 → 每条评论都要扫几百次字符串；或用 str_replace 全局替换 → 误伤“和谐”里的“和”，漏掉“河蟹”这种变形词。
- DFA 要求所有敏感词预加载进内存，适合词库稳定、更新不频繁的场景（如后台审核通过后才生效）
- ThinkPHP 默认不带 DFA 实现，别指望
validate规则或中间件里塞个in_array就能扛住并发评论 - 中文需按 UTF-8 字节切分，不能直接用
str_split，否则一个汉字被拆成 3 个乱码节点
怎么在 ThinkPHP 中手写轻量 DFA 树结构
不用引入第三方包，核心就两个类：一个构建树（DfaTreeBuilder），一个执行匹配（DfaFilter）。关键不是代码多，而是节点存储方式 —— 必须用索引数组而非对象，否则 PHP-FPM 下每次请求重建对象开销太大。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 把敏感词列表存在数据库表
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 倍
如何在评论提交时调用 DFA 并处理命中结果
别在控制器里临时 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，最后入库前再转义
为什么缓存失效和热更新会让 DFA 失效
树一旦生成就固定，数据库新增词不会自动进树。很多人以为改了数据库就能立刻生效，结果测试时一直不拦截新词。
解决方案只有两个方向：
- 运维侧：加个后台按钮，点击后执行命令
php think dfa:build，重新 dump 树文件并 touch 更新时间戳；Nginx 配置监听该文件mtime，变化后 reload worker - 开发侧：在
DfaFilter构造函数里加检查，如果filemtime(cache_path) ，就强制重建（仅限低频站点，慎用） - 绝对不要用
opcache_invalidate强刷缓存文件 —— 它在 CLI 模式下无效，且可能引发并发重建冲突
最常被忽略的一点：DFA 对大小写、全半角、简繁体完全敏感。要支持“微软”和“微軟”，得在入库时统一转简体+小写，而不是靠树来兼容 —— 树只做精确匹配，语义归一化必须前置。
