Navicat跨平台还原需手动对齐SQL文件编码、MySQL服务端字符集和连接层初始化命令；必须清理CRLF换行、UTF-8 BOM、Windows路径注释，并确保首行含SET NAMES utf8mb4；Linux版Navicat导入时需设置Use Unicode UTF-8及Initial command，且编码下拉菜单仅影响文件读取不改变执行字符集。
navicat 本身不支持 windows 到 linux 的「自动路径转换」或「编码重映射」，所谓“跨平台还原”不是一键动作，而是手动对齐三个关键层：sql 文件编码、mysql 服务端字符集、navicat 连接层初始化命令。直接双击导入或拖入 sql 文件大概率失败，尤其当文件含中文路径注释、windows 风格换行或 bom 头时。
导出的 SQL 文件在 Linux 上执行前必须清理 Windows 痕迹
Navicat 在 Windows 上导出的 SQL 文件默认带 CRLF 换行、可能含 UTF-8 BOM、且注释里常出现 C:\path\to\table.sql 这类绝对路径——Linux MySQL 客户端（如 mysql 命令行或 Navicat 自身）不会自动转换这些。
- 用
dos2unix或 VS Code 批量转 LF 换行：dos2unix backup.sql - 用 VS Code 打开 → 右下角点击编码 → Save with Encoding → UTF-8 (no BOM)
- 全局搜索替换掉所有 Windows 路径注释，例如把
-- Source: C:\projects\dump.sql改成-- Source: /home/user/dump.sql，否则某些解析器会报语法错误 - 检查文件开头是否有
/*!40101 SET NAMES utf8mb4 */;——没有就手动加，且确保它在第一行（不能前面有空行或 BOM）
Linux 版 Navicat 导入 SQL 时的编码陷阱
Linux 版 Navicat（尤其是 v16/v17）对文件编码更敏感：它读取 SQL 文件时依赖系统 locale，但执行语句时又只认连接层设置。如果系统是 en_US.UTF-8，而 SQL 文件是 GBK 编码，Navicat 会静默乱码解析，报错却指向表名或字段名不存在。
- 导入前先确认 Linux 终端 locale：
locale | grep UTF-8，不是就用export LANG=en_US.UTF-8临时设置 - 在 Navicat 连接属性 → 「高级」页中，必须勾选
Use Unicode UTF-8，并在Initial command框填入：SET NAMES utf8mb4; - 导入弹窗右下角的「编码」下拉菜单仅控制文件读取解码，**不改变 MySQL 执行时的字符集**——所以即使选了 UTF-8，若连接没设
SET NAMES，照样Incorrect string value - 别信「自动检测编码」，Linux 版 Navicat 的自动检测经常把 UTF-8 BOM 文件识别为 ISO-8859-1，导致中文全变问号
还原失败时优先排查这三处分隔符与路径问题
Linux 对路径分隔符极其严格，而 Navicat 在 Windows 导出时可能把本地路径逻辑混进 SQL（比如 LOAD DATA INFILE 语句、自定义函数路径、插件路径），这些在 Linux 上根本不可达。
- 搜索 SQL 文件中所有
LOAD DATA INFILE、DATA DIRECTORY、PLUGIN_DIR相关语句，全部删掉或注释掉——Navicat 的「运行 SQL 文件」功能不支持跨平台文件加载 - 检查是否有
CREATE FUNCTION ... SONAME 'xxx.dll'，Linux 上要改成.so，且路径得是 Linux 风格（/usr/lib/mysql/plugin/xxx.so） - Navicat 自带的「数据传输」功能比「运行 SQL 文件」更安全，它绕过 SQL 解析层，直连源/目标库搬运数据，自动处理字段类型映射和 NULL 值，适合大表迁移
- 如果必须用 SQL 文件，导出时在 Navicat 中取消勾选「包含创建数据库语句」和「包含存储过程/函数」——这些最容易因路径或权限失败
真正跨平台还原的关键不在 Navicat 界面操作多“顺”，而在于你是否愿意花两分钟检查 SQL 文件头、换行、BOM 和路径硬编码——这些细节 Linux 不会帮你容错，报错信息也往往不指向真实原因。
