根本原因是导出和导入两端字符集未对齐，需确保phpMyAdmin连接层设utf8mb4、导出时勾选SET NAMES并选utf8mb4编码、导入命令加--default-character-set=utf8mb4参数、SQL文件为UTF-8无BOM、建表语句显式声明DEFAULT CHARSET=utf8mb4。
根本原因不是文件“坏了”，而是导出和导入两头的字符集没对齐——尤其是连接层默认用了 latin1，把 utf-8 编码的中文当乱码解析了一次，再存进去就不可逆了。
导出时 phpMyAdmin 没走 UTF-8 连接路径
即使你数据库里数据是正常的，只要 phpMyAdmin 导出前没用 utf8mb4 连接 MySQL，它就会按默认 latin1 读取字段内容，导致中文在写入 SQL 文件时就被转成问号。常见触发点：
- 登录后顶部语言选了
Chinese simplified (zh-gb2312-utf-8)或带gb2312的选项，phpMyAdmin 会悄悄发SET NAMES gb2312覆盖连接设置 - 配置文件
config.inc.php里没显式设$cfg['Servers'][$i]['charset'] = 'utf8mb4' - 导出界面没勾选
Add SET NAMES statement，或Export character set下拉框选的是utf8（MySQL 8.0+ 已废弃）而非utf8mb4
导入命令没指定客户端字符集
用 mysql 命令行导入时，不加参数就等于让客户端用默认 latin1 解析整个 SQL 文件，哪怕文件开头有 SET NAMES utf8mb4，也挡不住第一行就被错解。必须显式声明：
- 导入命令必须带
--default-character-set=utf8mb4，例如：mysql --default-character-set=utf8mb4 -u root -p db_name < dump.sql - 别信
my.cnf里设了default-character-set就万事大吉——这个配置项在新版本 MySQL 中已被废弃，且不作用于客户端连接层 - 如果导入后查
SHOW VARIABLES LIKE 'character_set%'，发现character_set_client或character_set_connection是latin1，说明参数根本没生效
SQL 文件本身编码不是 UTF-8 无 BOM
编辑器显示正常 ≠ 文件真实编码正确。VS Code 默认可能存成 UTF-8 with BOM，而 MySQL 会把 BOM 当非法字符报错；记事本更常存成 GBK 或 ANSI。验证和修复方法：
- Linux/macOS 下用
file -i dump.sql看输出是否含charset=utf-8 - Windows 用户别用记事本“另存为 UTF-8”，改用 VS Code → 右下角点编码名 →
Save with Encoding→ 选UTF-8（**不是 UTF-8 with BOM**） - 若确认是
GBK编码，用iconv -f gbk -t utf8mb4 dump.sql > dump_utf8.sql转换
目标库建表语句没强制指定 DEFAULT CHARSET
就算导入命令和文件都对了，如果 SQL 文件里的 CREATE TABLE 没写 DEFAULT CHARSET=utf8mb4，MySQL 就按当前库的默认字符集建表——而这个默认值很可能是 latin1 或过时的 utf8（最多存 3 字节）。结果就是表建好了，但字段底层还是不支持 emoji 和部分生僻字。
立即学习“PHP免费学习笔记（深入）”；
- 打开 SQL 文件搜索
CREATE TABLE，每张表定义末尾手动补上：ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 已存在的乱码表不能只靠
ALTER TABLE ... CONVERT TO，得先用SELECT HEX(column_name)判定原始编码状态，再针对性修正列定义 - 检查
SHOW CREATE DATABASE db_name，确认库级默认字符集也是utf8mb4，否则新表仍会继承错误默认值
最容易被忽略的是：导出和导入是两个独立连接过程，各自都要确保 charset 显式生效。很多人修好了导出，却在导入时又掉回 latin1，白忙一场。
