php敏感词库性能太差怎么办？优化算法提升过滤效率

发布日期： 2025-10-03 阅读量： 作者： admin

得，今天聊聊我在PHP项目里头搞敏感词过滤那点事儿。项目要求对用户发的内容做个过滤，脏话、广告、不让说的那些词都得弄掉。最直接的想法，那肯定是PHP自带的str_replace函数嘛简单粗暴。

弄了个敏感词数组，大概几十个词，然后循环一遍，挨个替换成星号“”。刚开始用户少，词库也小，跑起来还行，没啥感觉。但后来产品那边要求越来越严，给的敏感词库一下子膨胀到好几千个，甚至上万个。这下坏了，再用老办法，一个请求进来，光循环替换这些词就得卡半天，CPU直接飙高，用户体验差得不行。

性能瓶颈来了，得想办法。

我就开始琢磨，网上到处翻资料。有人说用正则表达式，把所有敏感词用竖线连起来，搞成一个大的模式匹配。听起来好像挺牛，一次性匹配。我也试了试，写了个函数，把词库数组转成一个巨大的正则表达式字符串，类似/(词1词2词3...)/i这样，加了个i忽略大小写。效果嘛比循环str_replace稍微好点，但也好得有限。主要是这个正则表达式太大了，编译和匹配起来还是很吃力，而且维护起来也麻烦，词库里要是有正则表达式的特殊字符，还得一个个转义，头疼。

正则表达式也不是万能药。

继续找方案。这时候看到有人提到了DFA算法，说是状态机啥的，效率很高。看着挺高深，感觉自己从头写一个有点费劲。然后又看到另一个词：Trie树，也叫字典树。这个听起来稍微具体点，说是专门用来处理字符串查找和前缀匹配的，很适合敏感词过滤这种场景。

我看网上有些现成的PHP实现或者库。有的说性能不错，但可能不支持最新的PHP版本，比如看到有人说某个trie_filter扩展不支持PHP7啥的。当时我用的PHP版本还行，就想先找个现成的试试，或者自己照着原理简单实现一个。

决定用Trie树试试看。基本思路就是：

先把那个巨大的敏感词库文件读进来。
然后遍历词库，一个词一个词地往一个树形结构里塞。每个节点代表一个字符，从根节点到某个节点的路径就组成一个词。在代表词结尾的那个节点上做个标记。
这样，一个包含所有敏感词的Trie树就在内存里建好了。

构建Trie树的过程是关键。一次性把词库加载构建后面检查就快了。不过词库大的话，这树也挺占内存的。当时还特意用了ini_set('memory_limit', '...')调大了PHP脚本的内存限制，不然几万个词构建树的时候直接就内存溢出了。

过滤是怎么做的？

检查用户输入的内容时，就从头开始一个字符一个字符地读。在内存里的Trie树上，从根节点开始，顺着字符往下走。比如用户输入“我爱北京天安门”，先读“我”，在树里找有没有“我”开头的路径；再读“爱”，接着往下走... 如果走到某个节点，发现它被标记为“词结尾”，那就说明从根到这儿，匹配到了一个完整的敏感词。同时还要继续往下探，因为可能存在更长的敏感词，比如“天安”和“天安门”。要找到最长匹配的那个。

一旦找到一个敏感词，就把对应位置的字符替换成“”，然后从这个敏感词的结束位置继续往后检查文本。

这个方法的效率确实高多了。

因为它不是暴力地对每个敏感词去全文搜索，而是随着文本的读取，同步在Trie树里查找，基本就是遍历一遍文本的功夫，加上一些树节点查找的开销，比之前循环str_replace或者单个巨大正则表达式快了好几个数量级。内存占用虽然大了点，但在可接受范围。后面还搞了个小脚本，专门用来定时更新这个内存里的Trie树，当敏感词库文件有变动的时候，重新加载一下，不用重启整个服务。

总算是把这个敏感词过滤的功能给稳定高效地实现了。回想起来，从最简单的str_replace，到尝试正则表达式，再到选用Trie树，也是踩了不少坑，走了不少弯路。但搞定之后，还是挺有成就感的。

上一篇: php escape怎么用才最安全？防止SQL注入和XSS攻

php敏感词库性能太差怎么办？优化算法提升过滤效率

随便看看