导出SQL前必须将Navicat连接层字符集设为utf8mb4，包括勾选“使用自定义字符集”并手动输入utf8mb4，且在“初始化命令”中添加SET NAMES utf8mb4；否则即使导出文件编码选UTF-8，生成的SQL仍可能含utf8或latin1声明，导致emoji丢失或乱码。
导出SQL文件前必须设对连接层字符集
navicat「转储sql文件」时用的不是你编辑器里看到的编码，而是当前连接的字符集上下文。如果连接本身没设成utf8mb4，哪怕你在导出对话框里选了utf-8，生成的sql里建表语句、注释、字符串字面量仍可能被mysql按latin1或gbk解析——导出文件头甚至会硬写set names latin1。
- 右键连接 → 编辑连接 → 「高级」页签 → 勾选「使用自定义字符集」→ 手动输入
utf8mb4（别信下拉菜单，旧版Navicat常不显示） - 同时在「初始化命令」框填入：
SET NAMES utf8mb4;（注意是utf8mb4，不是utf8） - 点「测试连接」成功后，再执行转储——此时导出的SQL才会默认带
CHARACTER SET utf8mb4声明
导出对话框里的「文件字符集」只管保存编码，不管SQL内容
很多人以为在「转储SQL文件」→「高级」页里选了「UTF-8」就万事大吉，其实它只控制Navicat把生成的SQL文本以什么编码写进磁盘文件，完全不影响SQL语句里写的CHARACTER SET、COLLATE这些关键词。如果你连接层没设utf8mb4，导出的SQL里依然可能出现DEFAULT CHARSET=utf8或COLLATE=utf8_general_ci——这种脚本在现代MySQL上执行会存不了emoji，还原到新库也可能报错。
- 务必先确认连接层已生效：连上后执行
SHOW VARIABLES LIKE 'character_set_client';，返回值必须是utf8mb4 - 导出时「文件字符集」选
UTF-8（无BOM），这是VS Code/Notepad++等现代编辑器默认格式 - 如果目标环境是老旧系统（如某些Docker MySQL 5.1镜像），导出后需手动替换SQL文件里的
utf8mb4为utf8，但仅限万不得已——这会丢emoji和部分生僻汉字
导出后发现SQL里还有utf8而不是utf8mb4？检查数据库和表的实际字符集
Navicat导出时会忠实复制库/表/字段当前的字符集设置。如果源库建的时候用的是utf8（MySQL的阉割版3字节utf8），或者某张表被ALTER TABLE ... CONVERT TO CHARACTER SET utf8过，那导出的SQL里就会出现DEFAULT CHARSET=utf8，哪怕你连接设对了也没用。
- 查库级字符集：
SHOW CREATE DATABASE your_db;，看CHARACTER SET是不是utf8mb4 - 查表级字符集：
SHOW CREATE TABLE your_table;，重点看DEFAULT CHARSET和各字段的CHARACTER SET - 批量修正（执行前备份）：
ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;，再对每张表执行ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
导出的SQL文件开头没有SET NAMES声明？补上能防导入时乱码
Navicat默认导出的SQL不自动加SET NAMES，这意味着别人拿到这个文件，在其他客户端（比如MySQL命令行）里执行时，很可能因连接默认字符集不对而让中文变乱码。虽然「运行SQL文件」功能会读取连接配置，但纯文本导入场景下，这行声明就是保险绳。
- 在导出的SQL文件第一行手动插入：
/*!40101 SET NAMES utf8mb4 */;（用/*!...*/注释包裹，兼容性更好） - 别写
SET NAMES utf8——MySQL的utf8不支持4字节字符，utf8mb4才是真UTF-8 - 如果SQL文件里已有
CREATE DATABASE语句，确保它的CHARACTER SET也同步改成utf8mb4，否则新建库还是老编码
真正麻烦的从来不是选哪个下拉菜单，而是连接层、服务层、库层、表层四者字符集必须咬死对齐。少一个mb4，emoji就变成问号；漏一次SET NAMES，导入时注释就全糊成方块。
