根本原因是mysqldump默认用latin1读取utf8mb4库，导致字节错位解码使中文损坏；必须将--default-character-set=utf8mb4置于命令最前，且导入时同样需指定该参数。
mysqldump导出时中文变问号或乱码
根本原因是 mysqldump 默认用 latin1 读取表结构和数据，而你的库实际是 utf8mb4，导致字节错位解码。导出文件里中文已经损坏，后续再怎么改目标库设置都无效。
- 必须在命令最前面加
--default-character-set=utf8mb4，位置敏感，放后面无效 - 验证导出文件是否真为 UTF-8：
file -i your.sql应显示charset=utf-8；head -n 20 your.sql | grep CHARSET应看到DEFAULT CHARSET=utf8mb4 - 老版本 MySQL（utf8mb4，可降级用
utf8，但注意它不支持 emoji 和四字节 Unicode 字符 - 别用 PowerShell 重定向导出：
mysqldump ... > dump.sql会触发 UTF-16 编码，导致导入时报ASCII '\0' appeared in the statement错误；改用--result-file=dump.sql或 cmd.exe
mysql命令行导入后中文显示为?或方块
导入命令没指定字符集，MySQL 默认按 latin1 解析 SQL 文件，哪怕文件本身是 UTF-8 编码。
- 导入时必须显式加参数：
mysql -u root -p --default-character-set=utf8mb4 mydb - 如果已执行过错误导入，表里数据实际已存为乱码字节，此时改连接设置或表字符集都救不回来，只能从原库重导
- 用
LOAD DATA INFILE导入文本时，必须带CHARACTER SET utf8mb4子句，否则默认走character_set_database
SET NAMES utf8mb4 为什么只对当前会话有效
SET NAMES utf8mb4 是快捷方式，等价于同时执行：SET character_set_client = utf8mb4、SET character_set_connection = utf8mb4、SET character_set_results = utf8mb4。这三个变量作用域是 session 级，断开重连就失效。
- 永久生效需配客户端配置文件：在
my.cnf的[client]段加default-character-set=utf8mb4 - JDBC 连接字符串必须含两个参数：
?useUnicode=true&characterEncoding=utf8mb4，缺一不可 - MySQL Workbench 需在 Connection → Advanced → Others 中手动填
characterSet=utf8mb4 - 不要只设
character_set_server或character_set_database，它们不影响客户端连接层的解码行为
表声明了 utf8mb4，但字段插入后仍是乱码
表级 DEFAULT CHARSET=utf8mb4 只是新字段的默认值，已有字段的字符集由其自身定义决定。如果建表时写了 VARCHAR(255) CHARACTER SET latin1，那这个字段永远按 latin1 存储。
- 查字段真实字符集：
SHOW CREATE TABLE mytable，看每个VARCHAR字段是否带CHARACTER SET utf8mb4 - 批量修正字段：
ALTER TABLE mytable CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 单独改某字段：
ALTER TABLE mytable MODIFY COLUMN name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 注意：
CONVERT TO会重建表，大数据量时慎用；MODIFY COLUMN更精准，但需重写整个列定义
utf8mb4，只要某个字段是 latin1，它存进去就是错的，再也找不回来。
