中文乱码主因是连接层字符集未对齐：set names未生效致mysql误将utf-8字节当latin1解析写入；需确认phpmyadmin配置、sql文件无bom、建表显式声明default charset=utf8mb4，并导出时选zh-utf-8确保set names utf8mb4生效。
导入后中文全变乱码，基本可以断定是连接层字符集没对齐——SET NAMES 没生效，或压根没发，导致 MySQL 把 UTF-8 字节当 latin1 解，中文字段值直接被错解成乱码字节存进去。这不是显示问题，是写入时就错了。
检查 phpMyAdmin 连接层是否真用了 utf8mb4
登录 phpMyAdmin 后，直接在 SQL 页执行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;
三项必须全部返回 utf8mb4。只要有一个是 latin1 或 utf8（注意：MySQL 的 utf8 是 utf8mb3），说明连接初始化失败。常见原因：
-
config.inc.php里缺了$cfg['Servers'][$i]['charset'] = 'utf8mb4'、$cfg['Servers'][$i]['connection_charset'] = 'utf8mb4'、$cfg['DefaultCharset'] = 'utf8mb4'三行中的任意一个 - 改完配置没重启 Web 服务（Apache/Nginx）和 MySQL 服务，phpMyAdmin 不热加载
- MySQL 服务端
character_set_server仍是latin1，导致连接 fallback 到旧编码
确认 SQL 文件是 UTF-8 无 BOM 编码
文件在编辑器里“看着中文正常”，不代表编码正确。BOM（EF BB BF）会被 MySQL 当作非法开头字符，导致后续 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）。
建表语句里没写 DEFAULT CHARSET=utf8mb4
即使连接层和文件都对了，如果 CREATE TABLE 末尾没显式声明：
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
MySQL 就会按数据库默认字符集建表——而这个默认值大概率还是 latin1 或旧版 utf8。结果就是字段定义看似正常，但插入中文时被静默转码成问号。
实操建议：
- 打开 SQL 文件，全局搜索
CREATE TABLE，逐个检查结尾是否有上述声明 - 没有就手动补上；特别注意不能写
utf8，那是 MySQL 的残缺实现，不支持 emoji 和部分汉字 - 已有表修复不能只改 DDL，得用：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
别信“导出时选了 UTF-8”就安全
phpMyAdmin 导出页的 “Export character set” 下拉框只是摆设，它不影响 SET NAMES 命令内容，也不改变 INSERT 中字符串字面量的编码方式。真正起作用的是顶部 Language 选项：
- 选
Chinese simplified (zh-utf-8)→ 导出开头是SET NAMES utf8mb4 - 选
English（默认）→ 导出开头是SET NAMES latin1，哪怕数据库全是 utf8mb4，也会乱码 - 如果没看到
zh-utf-8，说明 phpMyAdmin 版本太旧或语言包被裁剪，需手动修改libraries/database_interface.lib.php第 168 行附近过滤逻辑
导出后务必用 head -n 5 your.sql 确认第一行是不是 SET NAMES utf8mb4，不是就白改。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
