stripos()最稳妥，但需用!== false判断；中文用mb_stripos()；like查询前用addcslashes()转义%_；百万数据勿php层匹配，应交数据库或建倒排索引。
PHP里用stripos()做基础模糊匹配最稳妥
多数场景下，你不需要正则、也不用装扩展，stripos() 就够用了——它不区分大小写、返回位置、没匹配就返回 false，比 strpos() 更贴近“用户想搜什么就出什么”的直觉。
常见错误是拿它和布尔判断硬套：if (stripos($text, $keyword))，一旦关键词在开头（位置 0），表达式就为 false，直接漏掉结果。必须用严格比较：
- ✅ 正确写法：
if (stripos($text, $keyword) !== false) - ❌ 错误写法：
if (stripos($text, $keyword))或if (stripos($text, $keyword) == true) - 注意
$keyword为空字符串时，stripos()返回0，需额外判断strlen($keyword) > 0
中文搜索别直接用preg_match()，先转mb_系列函数
PHP 默认的 preg_match() 在 UTF-8 下对中文支持脆弱：没加 u 修饰符会崩，加了又容易因 PCRE 版本差异出错；更麻烦的是，它匹配的是字节而非字符，一个中文占三字节，位置计算全乱。
真实项目里，只要不是要写复杂模式（比如“包含A且不包含B”），优先用 mb_stripos()：
立即学习“PHP免费学习笔记（深入）”；
- 它原生支持 UTF-8，不用手动
mb_internal_encoding('UTF-8')（但确保脚本文件本身是 UTF-8 编码） - 参数顺序和
stripos()一致，替换成本低 - 性能略低于
stripos()，但对千行以内文本几乎无感；万级数据才需考虑缓存或预处理
示例：mb_stripos($content, '搜索词', 0, 'UTF-8') —— 第三个参数是偏移量，第四个是编码（可省略，但显式写出更防坑）
LIKE 查询进 SQL 前，addcslashes() 比 mysqli_real_escape_string() 更准
很多人把用户输入直接拼进 LIKE '%{$kw}%'，只做常规 SQL 转义，忘了 % 和 _ 是通配符，会被 MySQL 当语法解析，导致查出不该出的数据，甚至被绕过权限。
mysqli_real_escape_string() 不处理这两个字符，必须手动转义。用 addcslashes() 最直接：
-
$safe_kw = addcslashes($kw, '_%\');—— 注意反斜杠也要转，否则自定义的转义符失效 - SQL 中写成：
WHERE title LIKE CONCAT('%', ?, '%') ESCAPE '\'，然后绑定$safe_kw - 别用
str_replace(['%', '_'], ['%', '_'], $kw)，它不能处理已存在的反斜杠，可能造成双重转义
百万级数据别在 PHP 层做模糊匹配，哪怕用array_filter() + stripos()
数组里循环查 10 万个字符串？PHP 解释器扛不住，内存涨得快，响应时间从毫秒变秒级。这不是算法问题，是执行环境错配。
能走数据库就走数据库，哪怕只是 SQLite 临时表；实在要 PHP 内存处理，有两个轻量替代：
- 用
foreach配合stripos()，别用array_filter()+ 匿名函数——后者多一层栈调用，压测下慢 15%~20% - 如果关键词固定、文本集稳定，提前用
preg_split()切分并建立简单倒排索引（比如['php' => [0, 24, 89]]），查的时候 O(1) - 真要全文检索，宁可上
sphinx或elasticsearch，PHP 层只做结果渲染
模糊匹配的边界很模糊：用户觉得“差不多就行”，但代码得知道什么时候该放手、交给更适合的工具。越早明确数据规模和实时性要求，越不容易在后期推翻重来。
