结论是php-trie或aho-corasick-php最靠谱；因str_replace和preg_replace在词库超500条、文本超1KB时卡顿严重，无法处理词根匹配与前缀/后缀模糊逻辑，且preg_replace有回溯爆炸风险。
直接说结论：用 Composer 库做实时敏感词过滤，php-trie 或 aho-corasick-php 是目前最靠谱的选择；但“高性能”不等于“开箱即用”，关键得绕开字符串编码、内存泄漏和热更新这三道坎。
为什么不用 str_replace 或 preg_replace 做敏感词过滤
这两个函数在词库超 500 条后就会明显卡顿，尤其当文本长度 >1KB 时，preg_replace 的回溯爆炸风险会让 CPU 瞬间拉满。更麻烦的是，它们无法支持“词根匹配”（比如“苹果”要同时命中“苹果手机”“iPhone苹果”），也做不到前缀/后缀模糊逻辑。
实操建议：
- 别把敏感词塞进正则表达式拼成一个大
/(苹果|华为|特斯拉)/i—— 词库一更新就得重编译，且无法支持动态插入 - 避免对每条文本都调用
file_get_contents读取词库文件 —— I/O 成为瓶颈，尤其在 CLI 持续运行的守护进程中 - 如果用
str_replace多次循环替换，记得用strtr替代 —— 它内部是哈希查表，比逐个str_replace快 3–5 倍
aho-corasick-php 的正确初始化姿势
这个库底层是 Aho-Corasick 自动机，适合多模式精确匹配，但默认构造方式会吃掉大量内存，且不支持运行时增删词。
实操建议：
- 词库必须提前去重并转为 UTF-8 编码 —— 否则中文词可能被切分成乱码字节，导致匹配失败
- 不要在每次请求中 new
AhoCorasick实例 —— 构建自动机耗时约 20–200ms（取决于词量），应复用单例或注入容器 - 用
buildFromStrings而非buildFromFile—— 后者会反复 fopen，而前者可配合 Redis 缓存序列化后的serialize($ac)结果 - 注意 PHP 版本兼容性：PHP 8.1+ 需用
v4.0+，旧版会报Return type declaration must be compatible
如何让敏感词库热更新不中断服务
大多数方案靠重启 Worker 进程实现更新，但实时审计场景下不能接受秒级不可用。真正可行的是双缓冲 + 原子切换。
实操建议：
- 维护两个
AhoCorasick实例：$ac_old和$ac_new，新词库构建完成后，用AtomicSwitch类做指针切换（仅需 1–2ns） - 词库变更监听走 Redis Pub/Sub，而不是轮询文件 mtime —— 减少无谓系统调用
- 切换后保留
$ac_old至少 30 秒，等所有正在执行的过滤请求完成，再unset—— 防止 PHP GC 提前回收引发 segfault - 别用
opcache_invalidate()刷词库文件 —— 它只清 opcode 缓存，对内存中的自动机构造毫无影响
真正难的不是加载词库，而是保证高并发下每个字符都被稳定归一化（比如全角空格、零宽空格、emoji 变体）后再进自动机；这部分没标准解法，得根据业务文本来源针对性预处理。
