乱码是数据库连接、表结构、php处理、http输出四层编码不一致叠加所致，必须逐层验证并统一为utf8mb4：确认表与字段实际使用utf8mb4、强制php连接指定charset=utf8mb4、确保php文件为utf-8无bom编码。
直接结论：乱码不是单一环节的问题，而是数据库连接、表结构、PHP处理、HTTP输出四层编码不一致叠加导致的。必须逐层验证，不能只改一处。
确认 MySQL 表与字段实际使用 utf8mb4
很多人以为建库时指定了 utf8 就够了，但 MySQL 的 utf8 实际是阉割版（最多 3 字节），不支持 emoji 和部分生僻汉字；真正兼容 UTF-8 全字符集的是 utf8mb4。
- 检查建表语句是否含
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 执行
SHOW CREATE TABLE your_table;，确认CREATE TABLE输出中每个VARCHAR字段后都带CHARACTER SET utf8mb4 - 若已有表，用
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;转换（注意备份）
强制 PHP 数据库连接使用 utf8mb4
即使表是 utf8mb4，如果连接层没声明，MySQL 默认仍按 latin1 或旧 utf8 解析请求，数据在传输中就被截断或转错。
- MySQLi 方式：连接后立即调用
$mysqli->set_charset('utf8mb4');（不是utf8） - PDO 方式：DSN 中必须显式包含
;charset=utf8mb4，例如$dsn = 'mysql:host=localhost;dbname=test;charset=utf8mb4'; - 避免用
SET NAMES utf8—— 它等价于SET CHARACTER SET latin1+SET collation_connection = latin1_swedish_ci，本质不可靠
检查 PHP 文件本身编码与 BOM 干扰
PHP 脚本文件若以 GBK/ANSI 或 UTF-8 with BOM 保存，会导致 header() 前意外输出空格或不可见字符，触发 headers already sent 错误，进而使 Content-Type 失效，浏览器回退到默认编码（通常是 ISO-8859-1）。
- 用 VS Code 或 Notepad++ 打开 PHP 文件 → “编码”菜单 → 确认显示为
UTF-8（不含 BOM） - 绝不能在
<?php前有任何空格、换行、BOM 字节（可用十六进制编辑器验证前 3 字节是否为EF BB BF） - 若用了
session_start()，它对输出更敏感，BOM 会直接报错
验证 HTTP 响应头与 HTML meta 是否双重保障
仅靠 <meta charset="UTF-8"> 不可靠：当 HTTP 响应头已声明 charset，浏览器优先信它；若响应头缺失或错误，meta 才起作用。两者必须一致且显式存在。
- 在 PHP 脚本最开头（任何
echo/print/HTML 输出前）加：header('Content-Type: text/html; charset=UTF-8'); - HTML 的
内第一行必须是：<meta charset="UTF-8">（不要用http-equiv形式） - 用浏览器 F12 → Network → 刷新页面 → 点击主文档 → 查看 Response Headers 中
Content-Type是否含charset=UTF-8
最容易被忽略的是：哪怕以上四层全对，如果用了 substr()、strlen()、ucfirst() 这类非多字节安全函数处理从数据库读出的字符串，依然会把 emoji 或中文拆成半个字节，显示为 或乱码 —— 此时必须换成 mb_substr()、mb_strlen() 等，并确保 mb_internal_encoding('UTF-8') 已设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
