根本原因是数据存储时字符集错误，需先确认并统一数据库、表、字段均为utf8mb4，导出时勾选“以UTF-8编码导出”并手动指定字符集为utf8mb4，导入前执行SET NAMES utf8mb4或确保目标库字符集匹配。
导出前确认数据库和表的字符集是否为 utf8mb4
phpMyAdmin 导出乱码的根本原因，往往不是导出操作本身，而是底层数据存储时就没用对编码。如果表用的是 utf8（即 MySQL 的 utf8mb3），哪怕导出选了 utf8mb4，生僻字（如「?」「?」）也早已被截断或替换成问号，导出只是把损坏的结果原样保存。
检查方法：在 phpMyAdmin 左侧选中数据库 → 点击「结构」→ 查看每张表的 Collation 列，应为类似 utf8mb4_unicode_ci 或 utf8mb4_0900_ai_ci；点击某表右侧的「操作」→ 滚动到底部确认 Collation 一致；再点「SQL」标签页，执行：
SHOW CREATE TABLE `your_table_name`;观察
DEFAULT CHARSET=utf8mb4 和字段级 CHARACTER SET utf8mb4 是否存在。
- 若发现是
utf8，需先转换：用ALTER TABLE `t` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;（注意备份） - 仅改表默认字符集（
ALTER TABLE t DEFAULT CHARACTER SET utf8mb4）不够，字段可能仍保留旧编码 - MySQL 5.7.7+ 默认支持 utf8mb4，但老版本需确认
innodb_large_prefix=ON和innodb_file_format=Barracuda
导出时必须勾选「以 UTF-8 编码导出」并手动指定格式
phpMyAdmin 的「导出」页面里，「格式」选 SQL 后，下方有「导出选项」折叠区。这里有两个关键勾选项容易被忽略：
- ✅ 必须勾选
以 UTF-8 编码导出（即使你导出的是 SQL 文件，这个选项控制的是文件本身的字节编码，不是 SQL 语句里的字符集声明） - ✅ 在「格式特定选项」里，找到
导出表的字符集，手动从下拉菜单选utf8mb4（不要依赖默认值，某些版本默认是utf8） - ⚠️ 如果导出 CSV，
以 UTF-8 编码导出依然要勾，且建议勾选包含列名并选择使用引号包裹字段，避免逗号、换行破坏结构
不勾 以 UTF-8 编码导出，生成的 .sql 文件实际是 latin1 编码，用文本编辑器打开会直接显示乱码，后续导入必然失败。
立即学习“PHP免费学习笔记（深入）”；
导入时也要匹配 utf8mb4，否则导出白做
导出用了 utf8mb4，不代表导入就自动安全。如果目标库仍是 utf8 或连接字符集不对，SQL 文件里的四字节字符会被 MySQL 拒绝或转成 ?。
- 导入前，在 phpMyAdmin 右上角点击「新建」→ 「SQL」，先执行：
SET NAMES utf8mb4;
- 或者在「导入」页面上传文件前，展开「格式特定选项」，确认
字符集下拉框选的是utf8mb4 - 更稳妥的做法：导入前先用
ALTER DATABASE `db_name` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;确保库级默认编码正确 - 如果用命令行导入：
mysql --default-character-set=utf8mb4 -u user -p db_name ，缺 <code>--default-character-set=utf8mb4参数会走默认 latin1
验证导出文件是否真含 utf8mb4 字节
别只信 phpMyAdmin 界面提示。最直接的验证方式是用命令行看文件头和生僻字字节：
- Linux/macOS 下：
file -i dump.sql应返回charset=utf-8（注意是 utf-8，不是 utf8） - 用
hexdump -C dump.sql | head -20查看开头，确认没有ef bb bf（BOM）—— phpMyAdmin 导出不带 BOM，带 BOM 反而容易导致某些导入工具报错 - 搜索一个已知的四字节字符（如 U+1F602 ?），用
xxd dump.sql | grep "f0 9f 98 82"验证该字符是否以四字节序列存在（f0 9f 98 82是 ? 的 UTF-8 编码）
如果 hexdump 里只看到 3f 3f（两个问号）或 ef bf bd（UTF-8 替换符），说明原始数据在导出前就已经损坏，得回源头查表和连接编码。
