Navicat在Mac上执行Windows导出的SQL文件报错，主因是BOM头、CRLF行尾符及Mac版“自动提交”选项干扰：需清除UTF-8 BOM（EF BB BF）、转LF换行、禁用“执行前自动提交”，并确保导入时勾选“使用UTF-8编码读取文件”。
navicat在windows上导出的sql文件在mac上执行报错，**绝大多数情况不是系统差异导致的，而是文件编码、行尾符或navicat gui选项行为不一致引发的**。mac版navicat对bom头、crlf/lf混用、以及某些勾选项更敏感，而windows版常默认“宽容”处理。
检查SQL文件是否含UTF-8 BOM头
Windows记事本或旧版Navicat导出时容易生成带BOM的UTF-8文件（EF BB BF），Mac版Navicat读取时可能将BOM误认为非法字符，导致首条语句（如CREATE DATABASE）解析失败，报错类似ERROR 1064 (42000)。
- 用VS Code或Sublime Text打开该SQL文件，右下角查看编码：若显示“UTF-8 with BOM”，需另存为“UTF-8”（无BOM）
- 命令行快速验证：
head -c 3 your_file.sql | xxd—— 若输出包含ef bb bf，说明存在BOM - Navicat导入窗口中，务必勾选“使用 UTF-8 编码读取文件”（该选项在Mac版界面中有时默认未启用）
确认行尾符是否为LF而非CRLF
Windows默认用\r\n（CRLF），Mac/macOS终端和部分Navicat组件更倾向\n（LF）。当SQL文件含大量INSERT语句且末尾有注释时，CRLF可能被误切分，造成语法截断。
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 用
file your_file.sql命令检查：若返回“CRLF line terminators”，说明是Windows风格 - 转为LF最简方式：
sed -i '' $'s/\r$//' your_file.sql（macOS sed）或dos2unix your_file.sql - 避免用TextEdit保存——它会悄悄改写行尾符；推荐用VS Code、BBEdit或命令行工具处理
关闭Navicat Mac版的「执行前自动提交」选项
Mac版Navicat在“运行 SQL 文件”对话框中有个隐藏较深的选项：“执行前自动提交事务”（Auto-commit before execution），默认勾选。若SQL文件含CREATE PROCEDURE等需显式DELIMITER的语句，该选项会干扰语句块边界识别，导致ERROR 1064或中途中断。
- 打开“运行 SQL 文件”窗口 → 点击右下角“高级”或“选项”按钮 → 取消勾选该选项
- 这个选项在Windows版中通常不出现或默认关闭，所以同一文件在Windows能过，在Mac就挂
- 若文件含存储过程，建议优先改用
mysql -u user -p db_name 命令行导入（配合<code>source或预处理DELIMITER）
真正跨平台可靠的SQL文件，必须同时满足：UTF-8无BOM + LF行尾 + 不依赖GUI特定选项。别指望Navicat导出即“全平台通用”——它的导出逻辑本身就不标准化，尤其在Mac端对边缘case容忍度更低。
