乱码本质是字符集在连接层、表字段或sql文件中被错误解释，需重点验证set names utf8mb4是否生效、导出文件开头是否为set names utf8mb4、以及show create table中字段是否显式声明utf8mb4字符集。
迁移后乱码不是“数据坏了”，而是字符集在某个环节被错误解释了一次或多次。核心要抓三个地方：导入时的连接层编码、表字段实际声明的字符集、以及原始 sql 文件里隐含的 set names 指令。
导入前必须手动执行 SET NAMES utf8mb4
phpMyAdmin 界面里选“UTF-8”或“utf8mb4”字符集，只影响它自己读 CSV 或 SQL 文件的解码方式，不等于 MySQL 连接层真用了 utf8mb4。很多环境默认还是 latin1。
- 打开 phpMyAdmin 的 SQL 标签页，先运行：
SET NAMES utf8mb4; - 再确认生效：
SELECT @@character_set_client;—— 返回必须是utf8mb4，不是latin1或utf8 - 如果返回不是
utf8mb4，说明 phpMyAdmin 底层连接没配对，此时导入任何文件都会错位
检查导出 SQL 文件开头的 SET NAMES 是不是你想要的
phpMyAdmin 导出时，SET NAMES 值由顶部 Language 选项决定，跟数据库实际编码无关。选 English 就是 SET NAMES latin1，哪怕你表全是 utf8mb4，导出内容也已损坏。
- 用
head -n 3 your_dump.sql（Linux/macOS）或用 VS Code 打开看前几行 - 必须看到
SET NAMES utf8mb4;—— 注意是utf8mb4，不是utf8（MySQL 8.0+ 已废弃utf8别名） - 如果看到
SET NAMES latin1或gb2312，说明导出时 Language 选错了；重新选Chinese simplified (zh-utf-8)再导出 - 导出页里那个 “Export character set” 下拉框只是摆设，改了也没用
表和字段的字符集不能靠“默认”继承
即使你新建库时勾了 utf8mb4，老表、老字段的字符集仍卡在旧值上。迁移后显示乱码，大概率是字段定义里还写着 CHARACTER SET latin1 或 utf8。
- 查真实定义：
SHOW CREATE TABLE your_table;—— 看每个VARCHAR字段末尾有没有CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 单字段修复（数据未损坏时）：
ALTER TABLE your_table MODIFY your_column VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 整表转换慎用：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;只适用于数据本身编码正确但声明错的情况；如果数据已被当 latin1 存过一次，这么转会二次损坏
别忽略 BOM 和编辑器二次转码
Windows 记事本保存的 “UTF-8” 实际是 UTF-8 with BOM（开头三个字节 EF BB BF），phpMyAdmin 会把它当普通字符吞掉，导致首字段内容偏移或乱码。
- 用 VS Code 或 Notepad++ 打开 SQL 或 CSV 文件，右下角看真实编码 —— 必须是
UTF-8 without BOM - Notepad++ 里选“编码 → 转为 UTF-8 编码”，不是“以 UTF-8 编码保存”（后者可能带 BOM）
- 导入 CSV 时，如果第一列全空或错位，八成是 BOM 搞的鬼
真正麻烦的不是操作步骤多，而是每个环节都可能静默失败：连接层用着 latin1，表字段声明着 utf8，SQL 文件里写着 SET NAMES gb2312，而你只改了其中一环。验证必须落到具体命令和返回值上，不能凭“我以为选对了”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
