乱码主因是编码不一致或mbstring未真正启用；需验证扩展加载、明确字符串原始编码、显式指定mb_substr编码参数，并区分mb_substr与mb_strcut的字符/字节截取逻辑。
直接结论：乱码大概率不是 mb_substr 本身的问题，而是编码不一致或 mbstring 扩展未生效导致的。
确认 mbstring 扩展是否真正启用
很多人以为在 php.ini 里取消了 ;extension=mbstring 的注释就完事了，但 PHP 实际加载的是哪份配置、有没有重启服务、是否被 CLI 和 Web SAPI 加载不同 ini 文件，都会导致扩展“看似开启实则未加载”。
实操建议：
- 用
php -m | grep mbstring检查 CLI 环境是否加载（别只信phpinfo()页面） - Web 环境下务必在脚本开头加
var_dump(extension_loaded('mbstring'));，不能只看 phpinfo 页面 - 如果返回
false，检查php --ini输出的配置路径，确认修改的是那个php.ini - Apache 下改完需
sudo systemctl reload apache2；PHP-FPM 需sudo systemctl reload php7.1-fpm
验证字符串原始编码是否为 UTF-8
mb_substr($str, 0, 5, 'utf-8') 不会自动转码 —— 它只是按 UTF-8 规则去解析字节流。如果传入的 $str 实际是 GBK 编码，却硬指定 'utf-8'，结果仍是乱码（或空字符串）。
实操建议：
- 用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true)粗略探测原始编码（注意第三个参数true表示 strict 模式） - 更可靠的方式是明确来源：数据库连接是否设了
charset=utf8mb4？HTTP 请求头是否声明Content-Type: application/json; charset=utf-8？文件本身是否保存为 UTF-8 without BOM？ - 临时强制转码：先
$str = mb_convert_encoding($str, 'UTF-8', 'auto')再截取（仅调试用，生产环境慎用'auto'）
检查 mbstring 内部编码设置是否干扰
PHP 7.1 默认不设 mb_internal_encoding，但一旦代码中调用了 mb_internal_encoding('GBK')，后续所有 mb_* 函数（包括 mb_substr）若省略 $encoding 参数，就会按 GBK 解析 —— 即使你传的是 UTF-8 字符串。
实操建议：
- 全局统一入口处显式设置：
mb_internal_encoding('UTF-8')，且确保它在任何mb_substr调用之前执行 - 永远显式传入
$encoding参数，例如写成mb_substr($str, 0, 10, 'UTF-8')，不要依赖内部编码 - 用
mb_internal_encoding()无参调用检查当前值，避免被框架或第三方库悄悄修改
对比 mb_substr 和 mb_strcut 的行为差异
两者都解决中文截取问题，但机制不同：mb_substr 按字符数截，mb_strcut 按字节数截（但保证不切断多字节字符）。如果你期望“最多取 10 个字节”，用后者；如果期望“最多取 10 个汉字”，必须用前者。
常见误用：
- 把
mb_strcut($str, 0, 10, 'UTF-8')当作mb_substr用，结果发现截出来只有 3 个汉字（因为 UTF-8 中 10 字节 ≈ 3 个中文字符） - 在不知道原始编码时混用：比如字符串是 GBK，却用
mb_strcut($str, 0, 10, 'UTF-8')，会导致字节解析错位，输出不可预测 - 错误地认为
mb_strcut更“安全”——其实它只避免字节断裂，不解决编码错配问题
最易被忽略的一点：即使 mbstring 扩展开着、编码也对，如果字符串里混有不可见控制字符（如 U+FEFF BOM、U+200B 零宽空格），mb_strlen 和 mb_substr 的计数仍可能出偏差。调试时先 bin2hex($str) 看真实字节流，比猜编码更直接。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
