直接用str_replace处理敏感词会越来越慢，因其时间复杂度为O(n×m)且无法处理子串重叠；应改用预编译Trie树，配合前缀后缀双检、内存常驻、Redis热更新等策略提升性能与准确性。
为什么直接用 str_replace 处理敏感词会越来越慢
当敏感词库超过 500 条，文本长度超 1KB 时，逐个 str_replace 就明显卡顿——它对每个词都扫一遍全文，时间复杂度是 O(n×m)，n 是词数、m 是文本长度。更糟的是，它无法处理“子串重叠”（比如词表里有 “法轮” 和 “法轮功”，只替换前者会导致后者残留）。
实操建议：
- 别把敏感词当普通字符串硬换
- 避免在循环里反复调用 str_replace 或 preg_replace 匹配全部词
- 敏感词加载进内存后，就别再从文件或数据库实时读了（IO 是最大拖累）
- 如果词表固定且不常更新，优先预编译成确定性有限状态自动机（DFA），也就是 Trie 树的运行态
用 PHP 实现基础 Trie 树并支持模糊匹配（如“*功”、“法*”）
Trie 树本身不支持通配符，但可以改造：把 * 当作通配分支节点，匹配任意单字；连续 * 则转为跳过若干字符。不过真实业务中，90% 的“模糊需求”其实是“前后缀截断”，比如“法轮功”要命中“法轮功组织”“抵制法轮功”，这时更稳的做法是：Trie 存原始词，匹配时用前缀+后缀双检，而不是在树里塞通配逻辑。
实操建议：
- 用关联数组模拟 Trie 节点，'is_end' => true 标记词尾
- 插入时统一转小写（或按需保留大小写），避免重复建分支
- 不要递归实现搜索，用 while 循环 + 指针变量遍历，防栈溢出
- 若需支持“同音字”“形近字”，别往 Trie 加权重或拼音映射——先做预处理：输入文本先过一遍 strtr 映射表，再进 Trie
$trie = [];
function insert(&$root, $word) {
$node = &$root;
for ($i = 0; $i < mb_strlen($word, 'UTF-8'); $i++) {
$char = mb_substr($word, $i, 1, 'UTF-8');
if (!isset($node[$char])) $node[$char] = [];
$node = &$node[$char];
}
$node['is_end'] = true;
}正则不是不能用，但得避开 preg_replace('/(法轮功|邪教|...)/u', '***', $text) 这种写法
这种写法在词少时没问题，但词一多，PCRE 编译就慢，而且 PHP 默认的 preg_replace 不支持“最长匹配优先”，容易把“法轮功”替换成“***”，却漏掉更长的“法轮功非法传播”里的“非法传播”判定逻辑（如果规则要求整句拦截）。
实操建议：
- 用 preg_quote($word, '/') 转义每个词，再拼接，避免正则元字符破坏模式
- 把所有词按长度倒序排列后再拼，确保“法轮功”优先于“法轮”匹配
- 单次调用 preg_replace_callback，在回调里做替换决策（比如根据上下文决定是掩码还是删整句）
- 禁用 /u 以外的修饰符，尤其别加 /i——中文没大小写，加了反而慢
线上环境必须加缓存层和 fallback 机制
哪怕 Trie 构建很快，PHP-FPM 每次请求重建树也是灾难。更麻烦的是，某些用户输入含 emoji 或私有 Unicode 区字符，Trie 遍历时可能崩在 mb_substr 上（返回 false），导致整段文本过滤失败却无报错。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 启动时用 opcache_compile_file() 预热词库文件，或把构建好的 Trie 数组存成 serialize() 后写入 APCu
- 在匹配循环里包 try/catch，捕获 mb_ 系列函数警告，遇到异常字符直接跳过该字节位置
- 设置超时阈值（比如单次过滤 > 50ms 就中断，返回原文+标记“疑似未过滤”）
- 敏感词更新不要 reload FPM，用 Redis 发布订阅通知各 worker 重新拉取 trie 数据
Trie 树不是银弹，真正难的从来不是“怎么建树”，而是“怎么让树在 10 万 QPS 下不出错、不漏词、不拖垮响应”。字符边界、编码混杂、内存碎片、OPcache 失效策略——这些地方不动手压测根本看不出问题。
