mb_strpos返回false但子串可见，主因是编码不匹配；必须显式传'utf-8'等编码参数，用mb_check_encoding()和mb_detect_encoding()验证一致性，排查数据库、http请求、字符串处理等链路的隐形编码污染。
mb_strpos 返回 false 但肉眼可见子串存在
这几乎一定是编码不匹配导致的。mb_strpos 不会像 strpos 那样“碰运气”地按字节扫描，它严格依赖字符边界和编码定义。如果 $haystack 和 $needle 的实际编码与 mb_strpos 当前使用的编码参数不一致，就会跳过匹配甚至直接返回 false。
常见诱因包括：
-
$haystack来自数据库（如 MySQL 默认 latin1 或 utf8mb4），但没显式指定encoding参数，导致mb_strpos按内部编码（可能是 ISO-8859-1）解析 UTF-8 字节流 - 前端 POST 过来的中文被 URL 解码后仍是 UTF-8，但服务端未调用
mb_internal_encoding('UTF-8')，且调用mb_strpos($str, $sub)时未传encoding - 字符串中混入了 BOM（如
\xEF\xBB\xBF）或不可见控制字符，mb_check_encoding()会返回false，但mb_strpos不报错，只静默失败
如何快速验证编码是否一致
别猜，用 mb_detect_encoding() + mb_check_encoding() 组合验证：
- 先检查两个字符串是否都有效：
mb_check_encoding($haystack, 'UTF-8')和mb_check_encoding($needle, 'UTF-8')必须都返回true - 再看检测结果是否可信：
mb_detect_encoding($haystack, ['UTF-8', 'GB2312', 'BIG5'], true)—— 第三个参数true表示“仅当唯一确定时才返回”，避免误判 - 如果检测出多个可能编码（比如返回
false或array('UTF-8','GB2312')），说明原始字节流本身有歧义，必须从源头统一为 UTF-8（如数据库连接加charset=utf8mb4，HTTP header 设Content-Type: text/html; charset=UTF-8）
mb_strpos 中 encoding 参数不传或传 null 的实际行为
PHP 8.0+ 允许 encoding 为 null，但它不会自动 fallback 到 mb_internal_encoding() 的值 —— 而是使用“当前区域设置的默认编码”，这个值在 CLI 和 Web SAPI 下可能完全不同（如 CLI 常为 C 或 POSIX，Web 常为 UTF-8，但不可靠）。
所以安全写法只有一条：
- 永远显式传编码：
mb_strpos($haystack, $needle, 0, 'UTF-8') - 不要依赖
mb_internal_encoding('UTF-8')后省略参数 —— 它只影响部分函数（如mb_strlen），对mb_strpos的encoding参数无强制约束力 - 如果业务必须支持多种编码（如读取旧 GBK 日志），请先用
mb_convert_encoding($str, 'UTF-8', $detected)归一化，再统一用 UTF-8 调用mb_strpos
中文子串查找失败时最该检查的三个位置
不是代码逻辑错，而是数据链路上的“隐形断点”：
- MySQL 查询前是否执行了
SET NAMES utf8mb4？或者 PDO DSN 是否包含;charset=utf8mb4？否则即使字段是utf8mb4_unicode_ci，返回的 PHP 字符串也是乱码字节流 - $_POST 或 $_GET 中的中文，是否被 Nginx/Apache 的某些模块（如 mod_security）截断或转义？可打印
bin2hex($_POST['text'])看是否出现非 UTF-8 的双字节序列（如a1a2、b0c4） - 字符串是否被
trim()、str_replace()等单字节函数污染过？例如trim($str, " \t\n\r\0\x0B")在 UTF-8 下可能切掉中文字符首字节，留下残缺多字节序列，mb_check_encoding()就会失败
真正麻烦的从来不是函数怎么用，而是你根本不知道哪个环节悄悄把 UTF-8 字符串变成了“看起来像中文的非法字节流”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
