必须在Navicat导出前将连接层字符集设为utf8mb4并勾选“导出为UTF-8编码”，否则即使文件保存为UTF-8，SQL内容仍含latin1声明或中文变???，因字符集在连接建立时即固定，导出环节无法补救。
导出前必须设对连接层字符集
navicat 导出 sql 文件时，字符集错误不是导出环节能补救的，而是从连接建立那一刻就定死了。如果连接本身用的是 latin1 或系统默认编码（windows 上常为 gbk），哪怕你后面勾选“导出为 utf-8 编码”，文件里中文字段照样变成 ??? 或导入时报 incorrect string value。
实操要点：
- 右键数据库连接 → “编辑连接” → 切换到「高级」页签
- 找到「字符集」下拉框，明确选
utf8mb4（不是utf8，后者不支持 emoji 和部分生僻字） - 保存并**重新连接**——旧连接不会自动刷新字符集设置
导出向导里“导出为 UTF-8 编码”必须勾选
这个选项控制的是 .sql 文件本身的文本编码，和数据库字符集是两层事。即使连接用了 utf8mb4，若没勾选此项，Navicat 仍可能按系统 locale（如 Windows 的 GBK）保存文件，导致用记事本打开看似正常，但 MySQL 客户端读取时直接报错。
位置在导出向导的「格式」页底部，不是默认开启的。常见误操作是只记得调连接字符集，却漏掉这一步。
注意：导出为 UTF-8 编码 生成的是无 BOM 的 UTF-8 文件，兼容性最好；不要手动用记事本另存为 UTF-8，它会偷偷加 BOM，MySQL 导入时可能跳过首行或报语法错。
大表导出失败或乱码？先查表级字符集
即使连接和导出设置都对，单张表的列定义若用了 latin1 或 utf8 字符集，导出的 INSERT 语句里对应字段值仍可能被转义异常，尤其含中文、emoji 的数据。
验证方式：
- 执行
SHOW CREATE TABLE table_name;，检查DEFAULT CHARSET和各TEXT/VARCHAR列的CHARACTER SET - 若发现不一致（比如表是
utf8mb4，但某列是latin1），导出后该列内容大概率损坏 - 临时补救：导出前用
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;统一转换
导出后验证乱码最直接的办法
别依赖双击用记事本打开——它会自动适配编码，掩盖问题。真正有效的验证方式只有两个：
- 用 VS Code 或 Notepad++ 打开 .sql 文件，右下角确认编码显示为
UTF-8（不是UTF-8 with BOM或GBK） - 在 MySQL 命令行里执行：
source /path/to/your/file.sql;，观察是否报Incorrect string value或插入后 SELECT 出来是问号
字符集问题往往在导入时才暴露，但根子在导出前的三处设置：连接字符集、导出编码选项、表自身字符集——少一个都可能让中文变 ???
