直接结论：不是SQL文件“坏了”，而是Navicat用错编码读取字节——必须同步控制文件编码、连接初始化、目标字段三者都为utf8mb4，缺一不可。
直接结论：不是sql文件“坏了”，而是navicat用错编码读取字节——必须同步控制文件编码、连接初始化、目标字段三者都为utf8mb4，缺一不可。
确认SQL文件真实编码是UTF-8无BOM
Navicat不会自动识别编码，它只按你选的选项硬解。选错就直接报语法错误或插入乱码。
- 用VS Code打开SQL文件，右下角看状态栏：显示
UTF-8（不是UTF-8 with BOM）才安全；若显示GBK或ANSI，必须另存为UTF-8（无BOM） - Linux/macOS下可用
file -i your.sql验证；Windows里chcp命令无效，别信 - Navicat导入窗口中，“使用UTF-8编码读取文件”勾选项必须手动开启（16+版本默认可能关闭）
导入前强制会话层用utf8mb4
SQL文件导入绕过常规连接初始化，SET NAMES utf8mb4不会自动执行——不手动设，服务器仍用latin1解析你的INSERT语句。
- 在Navicat当前连接的查询窗口里，先运行：
SET NAMES utf8mb4; - 更稳妥的做法：右键连接 → “连接属性” → “高级”页签 → 勾选“使用MySQL字符集”，并在“初始化命令”填入
SET NAMES utf8mb4; - 执行后立刻查
SHOW VARIABLES LIKE 'character_set%';，确认character_set_client、character_set_connection、character_set_results三者都是utf8mb4
检查目标表字段是否真支持utf8mb4
即使导入预览正常、没报错，SELECT出来仍是???，大概率是字段定义里没写死CHARACTER SET utf8mb4，还在用utf8（即utf8mb3）或latin1。
- 运行
SHOW CREATE TABLE `your_table`;，重点看每个中文字段末尾有没有CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 如果没写，哪怕表级用了
CONVERT TO CHARACTER SET utf8mb4，TEXT、MEDIUMTEXT等类型也可能漏掉，必须单独改：ALTER TABLE your_table MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 建库时没指定字符集的旧库，
character_set_database可能是utf8，新建表默认继承——不能只靠CONVERT TO兜底
最容易被忽略的是：utf8mb4需要服务端配置支持（max_allowed_packet、innodb_large_prefix等），但绝大多数乱码问题其实卡在文件编码、会话初始化、字段定义这三层对不齐。只要三处全对上，连emoji都能正常存。
