常见原因是源字符串编码与指定编码不符，如将gb2312误作gbk；应先用bin2hex或编辑器确认真实编码，再正确调用mb_convert_encoding($str, 'utf-8', 'gb2312')并检查输出环节。
mb_convert_encoding('GBK', 'UTF-8') 返回乱码的常见原因
不是函数本身出错，而是你传进去的字符串压根就不是 GBK 编码——它可能是 GB2312、GBK 的子集、带 BOM 的伪 UTF-8，或者混了多种编码。更常见的是：你用 file_get_contents 读了一个实际是 GB2312 的文件，却硬写 'GBK' 当源编码，结果 mb_convert_encoding 按 GBK 解释字节流，自然错位乱码。
确认源编码比盲目转换更重要
别信“看起来像 GBK 就是 GBK”。真实编码要靠字节特征判断：
- 用
bin2hex(substr($str, 0, 4))截前几个中文的十六进制，比如「你好」在 GB2312 是c4 e3+b7:7a，在 GBK 是c4 e3+b7:7a（多数兼容），但在 UTF-8 是e4 bd a0+e5:a5:bd -
mb_detect_encoding($str, ['GB2312', 'GBK', 'UTF-8'], true)可辅助，但返回false或'UTF-8'不代表准确，仅作参考 - 最可靠方式：查原始文件保存时的编辑器编码声明，或服务端文档说明（如老政务接口明确写“响应编码：GB2312”）
正确调用 mb_convert_encoding 的写法
三个参数一个都不能少，且顺序不能反：
- 目标编码必须写全大写或小写一致：
'UTF-8'（注意连字符），'utf8'在部分 PHP 版本可能被识别为ISO-8859-1 - 源编码要精确匹配，优先试
'GB2312'、'GBK'、'CP936'（Windows 简体中文默认） - 示例正确写法：
$utf8 = mb_convert_encoding($gbk_str, 'UTF-8', 'GB2312'); - 如果源编码不确定但知道是中文系编码，可传数组：
mb_convert_encoding($str, 'UTF-8', ['GB2312', 'GBK', 'BIG5'])，函数会逐个尝试
转换后仍乱码？检查输出环节是否被二次污染
转换成功 ≠ 浏览器能正确显示。常被忽略的断点：
- PHP 脚本自身保存编码不是 UTF-8 无 BOM：用 VS Code 打开，右下角确认是
UTF-8，不是UTF-8 with BOM或GBK - 没设响应头：
header('Content-Type: text/html; charset=UTF-8');必须在任何echo前执行 - HTML 中
<meta charset="UTF-8">写在最前面，且不能和header冲突 - 数据库或日志里存了转换后的字符串，但字段字符集仍是
latin1或utf8（非utf8mb4），导致入库时又被截断或转义
真正容易被忽略的点：mb_convert_encoding 对空字符串、null、含控制字符的字符串可能静默失败，返回原值；务必用 === false 判断是否转换失败，而不是只看是否为空。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
