Navicat导出CSV必须选UTF-8（非UTF-8-BOM），Excel须用“从文本/CSV”导入并手动选65001编码，数据库全链路需强制utf8mb4，否则必现乱码。
Navicat导出CSV时必须选UTF-8，不是UTF-8-BOM
navicat导出向导里的「编码」下拉框选utf-8，不是utf-8-bom。选错会导致文件实际写入的是无bom的utf-8字节流，但excel双击打开时仍按gbk解析——这不是excel错了，是它根本没机会识别编码。
容易踩的坑：
- 误以为“带BOM才安全”，在Navicat里选
UTF-8-BOM→ 实际导出内容反而可能被重复编码或截断 - 数据库连接层用的是
latin1或gbk，即使导出界面选了UTF-8，真实字节流仍是乱码 - 字段分隔符设成
;或\t，而Excel导入向导默认按逗号解析，导致列错位、中文被切开
Excel必须用“从文本/CSV”导入，不能双击
双击打开CSV走的是Windows系统默认ANSI路径，绕不开GBK；唯一可控入口是Excel的数据 → 从文本/CSV。这个操作不改原文件，也不依赖BOM，靠人工指定编码。
关键动作：
- 导入预览界面右下角
文件原始格式下拉菜单必须手动选65001: Unicode (UTF-8)，不能留“自动检测” - 若仍乱码，说明Navicat导出的字节流本身不是UTF-8 → 回头查
SHOW VARIABLES LIKE 'character_set%'，确认character_set_results是utf8mb4 - 勾选
首行为标题，否则第一行字段名会被当数据读入
导出前检查MySQL连接和表结构是否真用utf8mb4
Navicat显示正常、导出CSV也看着对，但Excel导入后还是问号？问题一定卡在数据库层。utf8mb4不是可选项，是硬性前提。
验证三处：
- 运行
SHOW CREATE TABLE your_table→ 字段定义里必须有CHARACTER SET utf8mb4（不是utf8） - 运行
SHOW CREATE DATABASE your_db→ 库级默认字符集必须是utf8mb4 - Navicat连接设置里「高级」页勾选
Use MySQL character set，下拉选utf8mb4，并在初始化命令填SET NAMES utf8mb4
临时救急：用Notepad++给CSV加BOM再双击
如果只是想让同事双击就能看，且你确认CSV内容确实是UTF-8（比如用VS Code打开右下角显示UTF-8），那就加BOM——这是Windows下唯一能让Excel自动识别UTF-8的方式。
操作步骤：
- 用Notepad++打开CSV → 菜单栏
编码 → 转为 UTF-8-BOM 格式→保存 - 不要用系统记事本另存为UTF-8：新版记事本默认不加BOM，旧版又可能把UTF-8当ANSI重写
- 空CSV文件加BOM后双击会显示一个
（U+FEFF）字符，此时应改用UTF-8 无BOM保存，再走导入向导
UTF-8 + Excel走从文本/CSV + 数据库全链路强制utf8mb4。漏掉任意一环，乱码就会在某个环节突然冒出来。
