strpos返回0时被if误判为false，因PHP松散比较将0视为假值；正确写法是用!== false严格比较；UTF-8字符串需用mb_strpos并指定编码。
因为 strpos() 返回的是位置索引（从 0 开始），而不是布尔值，而 0 在 PHP 松散判断中被当作 false，导致“找到了”却执行了“没找到”的分支。
返回 0 被误判为 false
strpos('hello', 'h') 返回 0，表示子串在开头；但 if(0) 会进入 else 分支。这不是 bug，是函数设计使然——它要同时表达“位置”和“未找到”，而 0 和 false 都是合法返回值。
- ❌ 错误写法：
if (strpos($str, $needle))、if (strpos($str, $needle) == false) - ✅ 正确写法：
if (strpos($str, $needle) !== false)
中文或 UTF-8 字符串匹配失败
strpos 按字节查找，UTF-8 中一个中文占 3 字节。用它查 '你好'，实际是在比对字节序列，极易因偏移错位而返回 false，哪怕字符串里真有这两个字。
- 必须改用
mb_strpos($str, '你好', 0, 'UTF-8') - 第四个参数 'UTF-8' 不能省，否则默认按单字节编码处理，结果不可靠
- 返回值同样要判
!== false，规则完全一致
大文件场景下内存爆炸
不是 strpos 本身的问题，而是常配合 file_get_contents() 使用——把整个 GB 级日志读进内存，PHP 还没开始搜索就 OOM 了。
立即学习“PHP免费学习笔记（深入）”；
- 应改用流式处理：用
fopen()+fgets()逐行读，或fread($fp, 8192)分块读 - 跨块匹配需手动维护缓冲区，防止关键词被切在两块之间
- 对含 BOM 的文件，先检测并去除
"\xEF\xBB\xBF"，避免干扰
其他易混淆的函数也踩同一坑
所有返回“整数位置 or false”的查找函数，都必须用严格比较：
-
stripos()（不区分大小写） -
strrpos()（找最后一次出现） -
mb_stripos()（多字节+忽略大小写） - 甚至
strrpos($filename, '.')提取扩展名时，遇到'.gitignore'也会返回 0，用== false就会误判为无点
