根本原因是phpMyAdmin导出时依据Language选项插入SET NAMES命令，而非数据库实际编码；选English会生成SET NAMES latin1导致中文注释乱码，仅选Chinese simplified (zh-utf-8)才生成SET NAMES utf8mb4确保正确解码。
phpMyAdmin 导出 SQL 时中文注释乱码，根本不是“注释写错了”，而是导出过程里 SET NAMES 指令和实际读取数据的字符集不一致导致的——注释本身没被转义，但 MySQL 在执行 SELECT 获取字段值、表结构、备注（COMMENT）时，用错了字符集去解码数据库里的原始字节。
导出时 Language 设置决定 SET NAMES，不是数据库实际编码
phpMyAdmin 不会根据你数据库的 character_set_server 或表的 COLLATION 自动推导导出字符集。它只看你顶部菜单选的 Language：
- 选
English→ 导出开头是SET NAMES latin1，哪怕所有表都是utf8mb4，注释里的中文也会被当成latin1解成乱码字节写进文件 - 选
Chinese simplified (zh-utf-8)→ 开头才是SET NAMES utf8mb4，此时注释、字段值、表名、列注释（COMMENT '用户昵称'）才能被正确读出 - 选
Chinese simplified (zh-gb2312)→ 注释按gb2312解，遇到 UTF-8 存储的注释就必然乱码
注意：自定义导出 页面里的 Export character set 下拉框只是影响导出文件的元数据和部分注释编码，**不改变 SET NAMES 值，也不影响对数据库内容的实际读取逻辑**。
注释乱码常被误判为“SQL 文件编码问题”
很多人用记事本或 VS Code 打开导出的 SQL，看到注释是乱码，第一反应是“文件保存错了编码”。但真实情况是：乱码字节在导出那一刻就已经写进文件了，编辑器只是忠实地显示它。
立即学习“PHP免费学习笔记（深入）”；
- 用
hexdump -C your.sql | head -n 5查看前几行，如果第一行是SET NAMES latin1，那后面所有中文注释都是错的，改文件编码毫无意义 - 即使文件是 UTF-8 无 BOM，只要
SET NAMES是latin1，MySQL 就会把存储为 UTF-8 的注释字段（比如information_schema.COLUMNS.COLUMN_COMMENT）强行按latin1解码，结果就是æ人这类字节序列，再写进 SQL 就是乱码 - 别信“导出后另存为 UTF-8”——那是二次污染，不是修复
旧版 phpMyAdmin 缺失 zh-utf-8 选项怎么办
phpMyAdmin 4.x 或精简包可能默认不显示 zh-utf-8，因为语言列表过滤掉了带 -utf-8 后缀的项。
- 打开
libraries/database_interface.lib.php，定位到约第 168 行附近，找到类似if (strpos($lang, '-utf-8') !== false) { continue; }的代码，把它注释掉 - 或者手动在
config.inc.php中强制指定语言：$cfg['Lang'] = 'zh-utf-8';（需确认该语言包实际存在） - 改完必须重启 Web 服务（Apache/Nginx），phpMyAdmin 不热加载语言配置
导出后务必检查 SQL 文件头：第一行必须是 SET NAMES utf8mb4，且没有 BOM；否则注释乱码问题一定存在，后续任何导入或编辑都只是在错误基础上打补丁。
