导出和恢复时均需显式指定 --default-character-set=utf8mb4，否则因客户端默认按 latin1 解析 UTF-8 字节流导致乱码（如 æ些æå）或问号。
mysqldump 时没加 --default-character-set 导致导出文件乱码
导出 SQL 文件本身是纯文本，但字符集声明缺失会让 MySQL 客户端按默认编码（通常是 latin1）解析二进制字节流，结果把 UTF-8 编码的中文当成单字节乱读——你看到的 æ些æå 就是典型表现。
实操建议：
- 导出时必须显式指定源库实际用的字符集，比如库是
utf8mb4，就加--default-character-set=utf8mb4 - 不要依赖
my.cnf里[client]段的设置——mysqldump默认只读[mysqldump]段，而该段默认不继承[client] - 如果不确定源库字符集，先查：
SHOW CREATE DATABASE `db_name`;看DEFAULT CHARACTER SET值
恢复时 mysql 客户端没设对字符集，SQL 文件里的中文变问号或乱码
即使导出正确，恢复时客户端仍可能用错编码读取 SQL 文件。比如文件是 UTF-8 编码，但 mysql 连接用 latin1 解析，INSERT 语句里的字符串字面量就会被错误转义。
实操建议：
- 恢复命令必须带
--default-character-set，且值要和导出时一致：mysql --default-character-set=utf8mb4 -u root db_name - 别信终端 locale 或系统编码——
mysql客户端只认自己参数或配置文件里的字符集声明 - 如果用
source命令在交互式客户端里执行，得先运行：SET NAMES utf8mb4;（注意不是SET CHARSET）
SET NAMES 和 --default-character-set 不是一回事
--default-character-set 影响的是客户端如何解码从服务器收到的数据、以及如何编码发给服务器的 SQL 字符串字面量；而 SET NAMES utf8mb4 是发一条命令告诉服务器：“接下来我发的 SQL 里字符串是 utf8mb4 编码，请按这个解码”。两者作用阶段不同，不能互相替代。
常见错误现象：
- 加了
--default-character-set=utf8mb4但没在 SQL 文件开头写SET NAMES utf8mb4;→ 恢复时若连接复用旧会话，可能沿用之前字符集 - SQL 文件里写了
SET NAMES latin1;但导出/导入都用utf8mb4→ 中文直接变?或截断 - 配置文件里
[client] default-character-set=gbk，但库是utf8mb4→ 全程错配，救不回来
备份文件本身编码和 MySQL 字符集是两层事
SQL 文件是文本文件，它有自己的文件编码（如 UTF-8 with BOM、UTF-8 no BOM、GBK），而 MySQL 的 character_set_client、character_set_connection 等变量控制的是 SQL 执行时的字符解释逻辑。文件编码不对，连第一行都读歪了。
实操建议：
- 用
file -i backup.sql或 VS Code 底部状态栏确认文件真实编码 - 别用 Windows 记事本保存 SQL 文件——它默认存为
GBK或带 BOM 的 UTF-8，MySQL 不认 BOM - 编辑备份文件后务必保存为 UTF-8 no BOM，并确保
--default-character-set=utf8mb4同步匹配
字符集问题从来不是单点故障，而是导出、文件存储、导入、服务端配置四者必须咬合。漏掉任意一环，中文就变成符号拼图。最常被忽略的是：你以为改了配置文件就生效了，其实 mysqldump 和 mysql 根本不读你改的那段。
