PHP线上编码失效的根本原因是环境差异，包括mbstring扩展未启用、Web服务器覆盖HTTP头、PHP文件含BOM、数据库连接编码未设等，需逐层排查而非仅改代码。
PHP 加编码（如 mb_internal_encoding() 或 header('Content-Type: text/html; charset=utf-8')）在本地正常、线上失效，根本原因几乎总是「环境差异」——不是代码写错了，而是线上 PHP 的扩展、配置或 Web 服务器层覆盖了你的设置。
确认 mb_internal_encoding() 是否真正生效
这个函数只影响 mbstring 扩展的内部编码行为（比如 mb_substr()、mb_strlen()），不改变 HTTP 输出或数据库连接编码。常见误用是以为设了它就能解决页面乱码。
- 必须在脚本最开头调用（不能在
include或函数里才设） - 检查是否启用了
mbstring扩展：var_dump(extension_loaded('mbstring'));—— 线上常因精简安装被禁用 - 验证当前值：
echo mb_internal_encoding();，别只信代码里写了就等于生效 - 如果返回
ISO-8859-1或空，说明没生效，优先查php.ini中mbstring.internal_encoding是否被设为静态值（会覆盖运行时调用）
HTTP 响应头被 Web 服务器或框架覆盖
你写了 header('Content-Type: text/html; charset=utf-8');，但浏览器开发者工具 Network 面板里看到的 Content-Type 是 text/html; charset=iso-8859-1？那大概率是 Apache/Nginx 或上层框架（如 Laravel、ThinkPHP）在你之前发了 header。
- Apache：检查
.htaccess有没有AddDefaultCharset ISO-8859-1这类指令 - Nginx：检查
charset指令是否全局设为utf-8或未设（未设时依赖 PHP 输出） - 框架：Laravel 默认在
App\Http\Kernel中注册了Illuminate\Http\Middleware\SetCacheHeaders，但不干预 charset；而某些国产框架会在基础控制器里强制重写 header - 调试技巧：在脚本开头加
var_dump(headers_sent($file, $line));，若返回true，说明 header 已被提前发送，定位到哪行、哪个文件
PHP 输出缓冲与 BOM 字节干扰
文件本身带 BOM（尤其是 UTF-8 with BOM 编码的 .php 文件），会导致 PHP 在输出任何内容前先输出 3 字节 EF BB BF，触发 header 自动发送，后续 header() 调用直接失败。
