乱码本质是数据库、表、字段三级字符集不一致导致navicat“硬解”字节出错；必须统一为utf8mb4：建库时指定character set utf8mb4，建表用convert to，字段逐个modify，并在navicat导入前执行set names utf8mb4且选对源文件编码。
直接结论：乱码不是导入动作本身导致的，而是数据库、表、字段三级字符集不一致，导致 navicat 读取字节时用错编码“硬解”。必须逐级检查并统一为 utf8mb4，不能只改其中一层。
查清数据库级默认字符集是否为 utf8mb4
Navicat 连上后执行：
SHOW VARIABLES LIKE 'character_set_database';如果返回值不是
utf8mb4，说明新建表默认会继承错误编码。这不是“服务端配置问题”，而是你创建数据库时没指定字符集。常见错误操作：
CREATE DATABASE mydb;（无 CHARACTER SET utf8mb4）正确写法：
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;已有数据库无法直接 ALTER 修改
character_set_database，只能重建或靠表/字段层兜底。
确认目标表的字符集和排序规则
执行：
SHOW CREATE TABLE `your_table`;重点看
CREATE TABLE 语句末尾是否带：ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci若显示
DEFAULT CHARSET=utf8 或为空（继承库级），就危险了。修复命令（注意不是只改表默认值）：
ALTER TABLE `your_table` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;这条命令会重写所有字段的字符集，比
ALTER TABLE ... DEFAULT CHARACTER SET 更彻底。
验证字段级是否真正用了 utf8mb4
即使表设对了，个别字段仍可能残留旧编码。执行：
SHOW FULL COLUMNS FROM `your_table`;检查
Collation 列——必须是 utf8mb4_unicode_ci 或类似 utf8mb4_0900_as_cs，不能是 latin1_swedish_ci 或空。若某字段仍是
latin1，手动修正：ALTER TABLE `your_table` MODIFY `column_name` VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;特别注意：TEXT、MEDIUMTEXT 字段也需单独
MODIFY，CONVERT TO 不保证覆盖所有类型。
Navicat 导入时未触发字符集协商，必须手动干预
导入动作（无论是 SQL 文件、Excel 还是 JSON）绕过了连接初始化流程，Navicat 不会自动执行 SET NAMES utf8mb4。
导入前务必在当前查询窗口中先执行：SET NAMES utf8mb4;
或者更稳妥地，在 Navicat 连接的「高级」设置里勾选「初始化命令」，填入该语句。
导入向导中「字符集」下拉框必须选 UTF-8（对应 utf8mb4），不是 GBK 或 Automatic；这个选项控制的是 Navicat 如何解析源文件字节流，和数据库字符集无关但必须匹配文件真实编码。
最易被忽略的一点：MySQL 的 utf8 是伪 UTF-8，最多存 3 字节字符；只要数据里有 emoji、生僻汉字或某些输入法词组，就必然丢字节变问号。从第一步建库开始就必须认准 utf8mb4，中间任何一层漏掉，都会让后续所有修复失效。
