MySQL连接层启用utf8mb4需在PHP中调用mysqli::set_charset('utf8mb4')或PDO DSN加charset=utf8mb4，同时确认表结构、字段、MySQL配置及PHP文件编码均为utf8mb4且无BOM。
确认 MySQL 连接层是否启用 utf8mb4
PHP 查询中文变问号，八成卡在连接字符集没设对。不是数据库表用了 utf8 就万事大吉——mysql_set_charset() 已废弃，mysqli::set_charset() 或 PDO::exec("SET NAMES utf8mb4") 才是生效入口。
常见错误现象：SELECT 返回全是 ????，但 phpMyAdmin 里数据正常；或插入成功、查询乱码。
- 用
mysqli时，必须在new mysqli()后立刻调用$mysqli->set_charset('utf8mb4')，不能靠配置文件或 SQL 语句补救 - 用
PDO时，DSN 中加;charset=utf8mb4（如mysql:host=localhost;dbname=test;charset=utf8mb4），比在PDO::exec()里 SET NAMES 更可靠 - 别用
utf8——MySQL 的utf8实际是utf8mb3，不支持 emoji 和部分生僻汉字；utf8mb4才是真 UTF-8
检查 CREATE TABLE 语句里的字符集和排序规则
即使连接层设对了，表或字段本身用的是 latin1 或 utf8，存进去就是错的，后续怎么查都救不回。
执行 SHOW CREATE TABLE your_table，重点看两处：
立即学习“PHP免费学习笔记（深入）”；
- 表级：末尾是否有
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 字段级：尤其是
VARCHAR类型字段，是否显式声明了CHARACTER SET utf8mb4
如果没配，改表命令得写全：ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci；只改 DEFAULT CHARSET 不影响已有字段定义。
验证 PHP 文件自身编码是否为 UTF-8 无 BOM
PHP 脚本里硬编码中文（比如 $sql = "SELECT name FROM user WHERE name = '张三'"），若文件保存为 GBK 或 UTF-8 with BOM，PHP 解析时会把字符串字面量当乱码处理，导致 SQL 传入错误字节流。
- 用 VS Code、Sublime 或 Notepad++ 查看右下角编码标识，强制转成
UTF-8（不是UTF-8 with BOM） - Linux 下可用
file -i your_script.php确认编码；head -n1 your_script.php | hexdump -C查 BOM（开头有ef bb bf就是带 BOM） - CLI 模式下运行脚本也受此影响，不只是 Web 环境
绕过 PHP 层直接测试 MySQL 字符集链路
当以上都确认无误仍乱码，说明问题可能出在更底层——比如 MySQL 配置未全局生效，或客户端协议被中间件劫持。
终端直连测试最干净：mysql -u root -p --default-character-set=utf8mb4，然后执行：
SET NAMES utf8mb4; SELECT '中文' AS test;
如果这步返回正常，说明服务端没问题；如果也变问号，就要查 MySQL 配置文件中 [client]、[mysqld]、[mysql] 三节是否都写了 default-character-set = utf8mb4（mysqld 节用 character-set-server）。
注意：修改 my.cnf 后必须重启 mysqld，仅 reload 不生效。
真正卡住人的，往往不是某一个设置，而是 utf8mb4 在连接、表结构、文件编码、MySQL 配置这四层里有一层漏了——少查一层，就得多花半小时反复试。
