循环调用preg_match_all检查70个敏感词是否存在性能问题？

首先直接说结论：你的当前实现确实有可优化的空间，不过以70个敏感词、单文本30-100词的规模来看，日常运行可能不会有明显的性能瓶颈，但优化后不仅能提升效率，还能避免潜在的正则匹配bug。

当前实现的几个核心问题： #

• 重复编译正则：每次循环里的preg_match_all都会重新编译对应的敏感词正则，70个词就会产生70次编译操作，虽然单次开销小，但属于没必要的资源浪费。
• 正则特殊字符未转义：如果敏感词里包含.、*、+这类正则元字符，当前代码会把它们当成正则语法处理，导致匹配出错（比如敏感词是a.b，会错误匹配acb而不是精确的a.b）。
• 不必要的全量匹配：preg_match_all会找出文本中所有匹配的敏感词，但你其实只需要知道「有没有匹配」就行，用preg_match足够——它找到第一个匹配就会停止，能节省不少资源。

推荐的优化方案： #

最核心的优化是把所有敏感词合并成一个正则表达式，只编译一次、匹配一次，效率会高很多。具体代码可以这么改：

// 取出所有启用的敏感词
$susWords = SuspiciousWord::where('checked', true)->pluck('word')->toArray();

// 转义每个敏感词里的正则特殊字符，避免匹配逻辑出错
$escapedWords = array_map(function($word) {
    return preg_quote($word, '/');
}, $susWords);

// 合并成一个正则，用|分隔，添加/i修饰符忽略大小写
$pattern = '/(' . implode('|', $escapedWords) . ')/i';

// 仅判断是否存在匹配，用preg_match足够
$foundSusWord = preg_match($pattern, $user->flirttext) === 1;

额外的优化建议： #

1. 缓存正则表达式：如果敏感词不会频繁更新，可以把编译好的正则缓存起来（比如用Redis、框架自带缓存或文件缓存），避免每次请求都重新构建正则，进一步提升性能。
2. 精确匹配调整：如果需要匹配完整的英文单词（比如不想让bad匹配badly），可以给正则加上单词边界\b——但注意这个只适合英文场景，中文没有单词边界概念，中文敏感词直接用上述模糊匹配即可。
3. 扩展性考虑：未来如果敏感词数量大幅增加，合并正则的方式依然能保持高效，而原有的循环遍历模式性能会随数量增长线性下降。

总的来说，当前实现虽然能工作，但优化后的版本更高效、更健壮，尤其是当敏感词数量未来增加时，优势会更明显。

内容的提问来源于stack exchange，提问作者Roman