答案是：执行SELECT @@character_set_client, @@character_set_connection, @@character_set_results;确认三者均为utf8mb4，否则客户端发送、服务端解析及结果返回环节将因编码不一致导致中文乱码或问号。
确认当前会话的三处字符集是否全为 utf8mb4
乱码不是数据“被改坏”，而是写入时就被错误解码了。必须立刻验证：@@character_set_client、@@character_set_connection、@@character_set_results 这三个值是否全是 utf8mb4。执行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;常见错误包括：
-
character_set_client是latin1：说明应用连接没带charset=utf8mb4参数 -
character_set_connection是utf8（即 utf8mb3）：会截断 emoji 或部分汉字，导致插入失败或乱码 -
character_set_results是gbk：即使插入成功，SELECT出来也会显示方块或问号
检查表字段是否显式声明 CHARACTER SET utf8mb4
别信 DEFAULT CHARSET=utf8mb4，它只影响新字段默认值，不覆盖已有字段。必须用 SHOW CREATE TABLE your_table; 逐行看字段定义，重点确认类似这样的写法：
name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci如果字段没显式声明，哪怕表级设了
utf8mb4，该字段仍可能继承旧库的 latin1。仅执行 ALTER TABLE t CHARACTER SET utf8mb4 是无效的——它只改元数据，不重建字段存储格式。
应用连接必须显式指定 charset=utf8mb4
数据库、表、字段全设成 utf8mb4，只要连接层没声明字符集，MySQL 仍按 latin1 解析请求，前面所有配置都白搭。不同场景写法不同：
- PHP PDO：
mysql:host=localhost;charset=utf8mb4必须写进 DSN - Java JDBC：
jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=utf8mb4，注意&要转义，驱动建议用 8.0+ - 命令行：
mysql --default-character-set=utf8mb4 -u root -p，否则默认用latin1 - Navicat：右键连接 →「编辑连接」→「高级」→ 勾选「使用 MySQL 字符集」并选
utf8mb4
SQL 文件导入前要验真实编码和加 SET NAMES
编辑器显示“UTF-8” ≠ 文件真是 UTF-8。Windows 上 VS Code 默认可能存成 UTF-8 with BOM，MySQL 会把开头的  当非法字符跳过，导致后续中文偏移解码。Linux/macOS 下用：
file -i your.sql看真实编码。若显示
charset=gbk 或 iso-8859-1，必须先转换：iconv -f gbk -t utf8mb4 your.sql > fixed.sql导入命令必须带参数：
mysql --default-character-set=utf8mb4 -u root -p db_name < fixed.sql且 SQL 文件第一行必须是：
SET NAMES utf8mb4;（必须在任何
USE 或 CREATE 之前）。
四者缺一不可：客户端声明、连接层转码、结果返回、字段存储——任意一层掉链子，中文就变问号。最容易被忽略的是连接层未显式传参，以及 SQL 文件带 BOM 却没察觉。 
