答案是乱码源于解码链断裂，必须统一character_set_client、character_set_connection、character_set_results为utf8mb4，并确认表结构与客户端连接参数均显式指定utf8mb4，否则即使服务端配置正确仍会乱码。
乱码不是数据坏了，是解码链断了——必须从连接层三变量（character_set_client、character_set_connection、character_set_results）开始查起，它们不一致或非 utf8mb4，就必然出问题。
查当前连接实际生效的字符集三变量
别信配置文件或建表语句，先看此刻这条连接到底用什么编码在传数据：
- 执行
SHOW VARIABLES LIKE 'character_set_%';，只盯这三项：character_set_client、character_set_connection、character_set_results - 如果其中任意一个是
latin1、gbk或utf8（注意：不是utf8mb4），而你的应用/终端实际发的是 UTF-8 字节，那返回结果必乱 - 常见错误现象：SELECT 出来是问号或 Mojibake（如 “æ些æ‡å”），但
SELECT HEX(col)显示的是合法的 UTF-8 字节序列（如E69FE4BAA7），说明写入没问题，只是读取时解错了
确认表和字段是否真用了 utf8mb4
即使连接层对了，表结构本身用错字符集，插入时就已损坏：
- 查表定义：
SHOW CREATE TABLE table_name;，确认DEFAULT CHARSET=utf8mb4且每个VARCHAR字段都显式声明了CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 别依赖数据库默认值——MySQL 5.7 默认
latin1，8.0 虽默认utf8mb4，但老表或迁移脚本可能没继承 - 已有表改字符集不能只跑
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4：如果字段定义里硬写了CHARACTER SET latin1，这条命令不会覆盖它，得补一句MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
检查客户端连接参数是否覆盖了服务端配置
很多人改完 my.cnf 就以为万事大吉，其实驱动连接时发的初始声明优先级更高：
- PHP PDO 必须带
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"或 DSN 加;charset=utf8mb4 - Python PyMySQL 连接时必须显式传
charset='utf8mb4'，漏掉就退化成latin1 - JDBC URL 必须同时含
useUnicode=true&characterEncoding=utf8mb4（注意是&，不是&；且必须是utf8mb4，utf8是 MySQL 的假 UTF-8） - Navicat / DBeaver 等 GUI 工具：连接设置里要单独勾选“使用 MySQL 字符集”并选
utf8mb4，光改软件界面编码没用
为什么改完还是乱？重点盯这几个地方
最常被忽略的其实是终端环境和驱动版本：
- Windows 命令行（CMD）默认用
GBK编码，即使你加了--default-character-set=utf8mb4启动mysql客户端，终端本身也解不开 UTF-8 字节——换用 Windows Terminal 或 WSL - Java 应用若用
mysql-connector-java5.x 或 6.x 驱动，即使 URL 写对了utf8mb4，也不支持四字节字符，必须升到 8.0+ -
SET NAMES utf8mb4只作用于当前会话，连接池复用旧连接时可能失效，必须在连接初始化阶段强制设置
