必须执行SELECT @@character_set_client, @@character_set_connection, @@character_set_results确认三项均为utf8mb4，否则连接层未生效；需同步修改config.inc.php中charset、connection_charset、DefaultCharset为utf8mb4并重启服务，且SQL文件须为UTF-8无BOM编码。
检查 phpMyAdmin 连接层字符集是否为 utf8mb4
phpmyadmin 5.1+ 默认用 set names utf8 初始化连接，而 mysql 的 utf8 实际是 utf8mb3，不支持四字节字符（如部分生僻汉字、emoji），导致中文被截断或转成问号。这不是页面显示问题，是协议层解码失败。
实操建议：
- 登录 phpMyAdmin 后执行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;—— 三项都必须返回utf8mb4 - 若不是，说明连接层没生效；不要只改数据库或表的 collation，那只是存储层，救不了导入时的解析
- 编辑
config.inc.php，在对应服务器配置块里加三行（缺一不可）：$cfg['Servers'][$i]['charset'] = 'utf8mb4';$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4';$cfg['DefaultCharset'] = 'utf8mb4'; - 改完必须重启 Web 服务（Apache/Nginx）和 MySQL 服务，phpMyAdmin 不热加载配置
确认 SQL 文件是 UTF-8 无 BOM 编码
文件显示“中文正常”不等于编码正确。VS Code 显示中文 ≠ 文件是 UTF-8；记事本另存为“UTF-8”默认带 BOM，MySQL 会把 EF BB BF 当作非法开头字符，导致后续 CREATE TABLE 或 INSERT 语句错位解析。
实操建议：
- Linux/macOS 下用：
hexdump -C your.sql | head -n 1—— 看前三个字节是不是ef bb bf - 有 BOM 就删：
sed -i '1s/^\xEF\xBB\xBF//' your.sql - Windows 下用 VS Code 打开 → 右下角点编码名 → “Save with Encoding” → 选
UTF-8（注意不是UTF-8 with BOM） - 别信“另存为 UTF-8”，要明确选“UTF-8 (no BOM)”或“UTF-8 without signature”
验证建表语句是否显式声明 DEFAULT CHARSET=utf8mb4
即使导入过程没报错，如果 CREATE TABLE 语句末尾没写 DEFAULT CHARSET=utf8mb4，MySQL 会按数据库默认字符集建表——而这个默认值往往是 latin1 或旧版 utf8，中文字段存进去就是问号或截断。
实操建议：
- 打开 SQL 文件，搜索
CREATE TABLE，每张表定义结尾检查是否有：ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 没有就手动补上；注意不是
utf8（MySQL 的utf8是残缺实现） - 已有表修复不能只改表定义：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci—— 这条会连数据一起转码 - 执行前先备份，
CONVERT对大表可能锁表、耗时长
导入时别依赖“文件的字符集”下拉框
phpMyAdmin 导入界面有个“文件的字符集”选项，但它只影响文件读取阶段的字节解释，不改变 MySQL 连接层的实际 character_set_client。选错只会雪上加霜，比如选 gbk 却传 UTF-8 内容，直接报错。
实操建议：
- 这个下拉框**留空或选 auto**，让 phpMyAdmin 按连接层设置自动处理
- 真正起作用的是前面说的连接层三变量 + 文件真实编码 + 建表语句字符集，三者必须一致
- 如果非要用它：仅当你的 SQL 文件确实是 GBK 编码（比如从老系统导出），才选
gbk，同时确保数据库、连接、表全设为gbk_chinese_ci—— 但强烈建议统一迁移到utf8mb4
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
