移动端PHP页面乱码的核心原因是HTML声明编码与PHP实际输出字节流不一致，必须统一使用UTF-8无BOM格式、正确设置Content-Type响应头、并确保MySQL连接及表结构均为utf8mb4。
移动端访问 PHP 页面显示乱码，核心原因几乎总是 HTML 声明的字符编码与 PHP 实际输出的字节流不一致，而 UTF-8 是唯一应选的编码方案。
PHP 文件本身必须保存为 UTF-8 无 BOM 格式
很多编辑器（如 Windows 记事本、旧版 Notepad++）默认保存带 BOM 的 UTF-8，PHP 解析时会把 BOM 当作输出内容提前发送，导致 header() 函数失效、session_start() 报错，且浏览器无法正确识别后续 <meta charset="utf-8">。
- 用 VS Code、Sublime Text 或新版 Notepad++ 打开 PHP 文件，检查右下角编码显示，手动转为
UTF-8（不是UTF-8 with BOM）并保存 - Linux/macOS 下可用命令快速检测：
file -i yourfile.php；若显示charset=utf-8-bom，说明有 BOM，需重新保存 - PHP 中任何
echo、print或 HTML 内容前都不能有空格、换行或不可见字符 —— BOM 就是典型“看不见的前置输出”
PHP 输出前必须设置 Content-Type header
仅靠 HTML 中的 <meta charset="utf-8"> 不可靠，尤其在移动端 Safari、部分 Android WebView 中，浏览器可能在解析到 meta 标签前就按默认编码（如 ISO-8859-1）解码了响应体，造成乱码。必须由服务器明确声明。
- 在所有输出（包括 HTML 开头）之前调用：
header('Content-Type: text/html; charset=utf-8'); - 该语句必须出现在任何实际输出之前；若用了
require/include，确保被包含文件也无 BOM、无空白 - 如果使用框架（如 Laravel、ThinkPHP），通常已在基础响应类中设置，但自定义输出（如
echo纯 HTML）时仍要确认是否绕过了框架响应流程
HTML meta 标签位置与写法必须规范
<meta charset="utf-8"> 必须位于 <head> 内、且尽可能靠前（建议作为 <head> 的第一个子元素），否则部分浏览器可能已开始解析后续内容。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“PHP免费学习笔记（深入）”；
- 写法只能是
<meta charset="utf-8">—— 不要用<meta http-equiv="Content-Type" content="text/html; charset=utf-8">，后者已被废弃且兼容性差 - 不能写成
UTF8、utf8或UTF-8（注意连字符）以外的形式；虽然多数浏览器宽容，但 iOS WebKit 对大小写和格式更敏感 - 如果页面通过 AJAX 加载 HTML 片段，该片段自身也需含完整
<meta charset="utf-8">，不能只依赖主页面
数据库连接与查询也需显式指定 utf8mb4
即使页面编码全对，若从 MySQL 读出的数据本身是 latin1 编码或连接未声明字符集，PHP 输出的仍是乱码字节 —— 此时浏览器按 UTF-8 解码，自然显示为方块或问号。
- MySQLi 连接后立即执行：
$mysqli->set_charset('utf8mb4'); - PDO 构造时在 DSN 中加入：
charset=utf8mb4，例如mysql:host=localhost;dbname=test;charset=utf8mb4 - 确认数据库、表、字段的默认字符集均为
utf8mb4（不是utf8），否则 emoji 和部分生僻汉字会截断或乱码
真正容易被忽略的是：BOM 问题常隐藏在被 include 的配置文件里，而数据库连接编码又常被写在 DAO 类底层，排查时容易只盯 HTML 和 header —— 实际上三者（文件编码、HTTP 响应头、DB 连接）缺一不可，且任意一个环节出错都会表现为“移动端乱码”。
