必须执行SELECT @@character_set_client, @@character_set_connection, @@character_set_results验证三值全为utf8mb4，再检查SHOW CREATE TABLE中字段是否显式声明CHARACTER SET utf8mb4。
UPDATE 后中文变问号或乱码，不是数据被“改坏了”，而是写入时就被错误解码了——必须同步确认 character_set_client、character_set_connection、character_set_results 和字段实际编码这四者全为 utf8mb4，缺一不可。
怎么立刻验证当前会话的三处运行时字符集？
别查配置文件，直接连上 MySQL 执行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;
结果必须全是 utf8mb4。常见错误包括：
-
character_set_client是latin1：说明应用连接没带charset=utf8mb4参数，或命令行没加--default-character-set=utf8mb4 -
character_set_connection是utf8（即 utf8mb3）：MySQL 会截断 4 字节 UTF-8 字符（如 emoji），导致写入失败或乱码 -
character_set_results是gbk：即使写入正确，SELECT 出来也会显示为方块或问号 - Navicat/DBeaver 当前会话是旧连接，改了设置但没断开重连，值不会刷新
表字段真用的是 utf8mb4 吗？别信 DEFAULT CHARSET
SHOW CREATE TABLE your_table; 查看建表语句，重点盯两处：
- 每条中文字段定义是否显式写了
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci？例如：name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 建表语句末尾是否有
DEFAULT CHARSET=utf8mb4？没有的话，字段可能继承自旧库的latin1
仅执行 ALTER TABLE t CHARACTER SET utf8mb4 是无效的——它只改元数据，不重建字段存储格式。真正生效的是：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：大表会锁表、重建索引、占用双倍临时空间，务必选低峰期操作。
SQL 文件里执行 UPDATE 仍乱码？先看文件真实编码
编辑器显示“UTF-8” ≠ 文件真是 UTF-8：
- Windows 上 VS Code 默认可能存成
UTF-8 with BOM，MySQL 会把开头的当非法字符跳过，导致后续中文偏移解码 - Linux/macOS 下用
file -i your.sql看真实编码；若显示charset=iso-8859-1或gbk，说明是错的 - GBK 编码文件不能直导：用
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之前）
UPDATE 成功但 SELECT 还是乱码？COLLATE 错了也会翻车
字段字符集对了，排序规则（COLLATE）错，照样乱码。比如：
- 字段是
utf8mb4，但COLLATE是utf8mb4_general_ci（已废弃）或utf8mb4_bin（区分大小写且排序异常） - 推荐统一用
utf8mb4_unicode_ci或 MySQL 8.0+ 的utf8mb4_0900_ai_ci - 修改单列排序规则：
ALTER TABLE t MODIFY name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -
CONVERT(name USING utf8mb4)只是临时转输出，不能修复底层错配——它只是把一堆错字再映射一遍，属于补救，不是根治
最易被忽略的点：客户端终端本身编码（如 Windows CMD 默认 GBK）、IDE 控制台输出编码、甚至日志系统解码方式，都可能让“看起来乱码”的问题出现在链路末端，而非数据库内部。
