答案是连接层字符集不一致导致乱码，必须确保character_set_client、character_set_connection、character_set_results三者均为utf8mb4，否则即使表和库设为utf8mb4，中文插入仍会变问号。
utf8mb4，中文插入后就大概率变问号或乱码——改表、改库、改配置文件都白搭，问题出在连接握手那一秒。
查当前会话真实字符集
连上 MySQL 后立刻执行：
SHOW VARIABLES LIKE 'character\_set%';重点关注上面三个变量值。别信
my.cnf 里写的 character-set-server=utf8mb4，它只影响新库，默认不生效于当前连接。常见错误现象：
character_set_client 是 latin1 或 utf8（注意：不是 utf8mb4），哪怕表和字段全是 utf8mb4_unicode_ci，插入的中文也会被截断成 ???。
连接字符串必须显式带 charset=utf8mb4
这是最常被跳过的环节。ORM、驱动、命令行工具，都得在建立连接时声明编码，否则 MySQL 默认按 latin1 解析请求包。
不同场景写法：
- PHP PDO：
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION不够，DSN 必须含charset=utf8mb4，例如：mysql:host=localhost;dbname=test;charset=utf8mb4 - Java JDBC：
jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=utf8mb4，注意&要转义，且characterEncoding值必须是utf8mb4，不能是UTF-8或utf8 - 命令行导入：
mysql --default-character-set=utf8mb4 -u root -p db_name ，漏掉 <code>--default-character-set=utf8mb4就默认走latin1 - Node.js mysql2：
{ charset: 'utf8mb4', collation: 'utf8mb4_unicode_ci' }，只设charset不配collation可能触发隐式转换
SET NAMES utf8mb4 不能替代连接参数——它只是会话级补救，如果初始握手已用错编码解析，后续再 SET 已无法恢复原始字节。
改表和字段要真正“转”数据，不是只改声明
ALTER TABLE t CHARACTER SET utf8mb4 这类语句只改元数据，字段底层存储仍按旧编码读写，无效。
必须用 CONVERT TO 或 MODIFY 显式重写内容：
- 整张表（含所有文本字段）：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci；大表慎用，会锁表、重建索引、占双倍临时空间 - 单个字段（更安全）：
ALTER TABLE t MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci；注意必须重写完整定义，否则可能丢NOT NULL、DEFAULT等约束 - 已有数据已乱码？
CONVERT TO不会修复脏数据，只能防止新数据再乱；已存的???需从源系统重导
SQL 文件本身编码也得是 UTF-8 无 BOM
编辑器显示正常 ≠ 文件编码正确。VS Code 默认可能存成 UTF-8 with BOM，MySQL 会把 BOM 当非法字符报错；记事本常存成 GBK。
验证与修复：
- Linux/macOS：
file -i dump.sql，输出含charset=utf-8才可信 - Windows：用 VS Code 打开 → 右下角点编码名 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - 若确认是
GBK编码：iconv -f gbk -t utf8mb4 dump.sql > dump_utf8.sql
最后提醒一句：MySQL 的 utf8 不是真正 UTF-8，它最多支持 3 字节，存不了 emoji 和部分生僻汉字；utf8mb4 才是唯一可靠选项。漏掉任意一环——客户端连接、SQL 文件编码、表字段定义、服务端默认值——都可能导致中文在某个环节被无声截断。
