中文变问号最直接原因是character_set_client、character_set_connection、character_set_results三项未统一为utf8mb4；文件需UTF-8无BOM，MySQL服务端、phpMyAdmin配置、建表语句及会话设置均须同步生效。
character_set_client、character_set_connection、character_set_results 这三项没对齐，是中文变问号最直接的原因。
不是文件坏了，也不是数据丢了，只是 MySQL 在某一层把 UTF-8 字节当 latin1 解了。执行 SHOW VARIABLES LIKE 'character\_set%';，如果这三项里有任意一个是 latin1 或 utf8（注意：MySQL 的 utf8 是 utf8mb3），中文写入/读出时就会被截断或替换成 ?。
导入前必须确认 SQL 文件真实编码是 UTF-8 无 BOM
VS Code 显示“UTF-8” ≠ 文件真是 UTF-8 编码；记事本“另存为 UTF-8”默认带 BOM，MySQL 会把 BOM 当非法字符丢弃，导致后续所有中文解析错位。
- Linux/macOS 下用
file -i dump.sql查真实编码，输出含charset=utf-8才可靠 - Windows 用户务必用 VS Code 打开 → 右下角点编码名 → “Save with Encoding” → 选
UTF-8（**不是** UTF-8 with BOM） - 已有 BOM 文件可用
sed -i '1s/^\xEF\xBB\xBF//' dump.sql去掉（Linux/macOS）
phpMyAdmin 界面设置和后端配置必须同步生效
右上角“Character set of the file”选 utf8mb4 只影响本次导入解析，不改变连接层编码。如果 MySQL 服务端 character_set_server 还是 latin1，或者 phpMyAdmin 的 $cfg['Servers'][$i]['charset'] 没设成 utf8mb4，照样出问题。
立即学习“PHP免费学习笔记（深入）”；
- 检查 MySQL 配置文件（如
/etc/mysql/my.cnf），在[mysqld]段加：character-set-server = utf8mb4collation-server = utf8mb4_unicode_ci - 修改 phpMyAdmin 的
config.inc.php：$cfg['Servers'][$i]['charset'] = 'utf8mb4';$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4'; - 改完必须重启 MySQL、Web 服务器（Nginx/Apache）、PHP-FPM，缺一不可
建表语句里没写 DEFAULT CHARSET=utf8mb4，埋下乱码隐患
即使导入过程没报错，只要 SQL 文件里的 CREATE TABLE 没显式声明 DEFAULT CHARSET=utf8mb4，MySQL 就按当前库的默认字符集建表——而这个默认值很可能还是 latin1 或过时的 utf8。
- 用文本编辑器打开 SQL 文件，搜索
CREATE TABLE，在每条语句末尾补上：ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; - 如果表已存在且中文显示为
???，先用SELECT HEX(column_name) FROM table_name LIMIT 1;看返回值：
若结果像E4B8ADE69687（UTF-8 编码的“中文”），说明数据本身是对的，只需改列声明：ALTER TABLE table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
真正容易被忽略的是：SET NAMES utf8mb4 只对当前会话有效，而 phpMyAdmin 导入是新建连接执行的，它不会自动帮你执行这条命令——你得靠配置文件、客户端参数、SQL 文件头三行注释（/<em>!40101 SET NAMES utf8mb4 </em>/）三层兜底，少一层都可能漏掉。
