Navicat执行SQL脚本报“Unexpected token '\r'”是因Git跨平台换行转换导致的混合换行符问题，需统一配置.gitattributes（*.sql text eol=lf）并执行git rm --cached -r . && git reset --hard，或用dos2unix清理文件。
navicat 本身不处理脚本文件的换行符转换，它只是原样读取、执行 sql 文件内容。所谓“lf/crlf 冲突”，实际是 git 在跨平台拉取或提交 sql 脚本时自动转换换行符，导致 navicat 执行时遇到非标准换行（比如 windows 下看到 \r\n 被误判为非法字符），或 prettier/eslint 报 delete ␍ 错误——这不是 navicat 的 bug，而是 git + 编辑器 + 工具链协同失准。
Navicat 执行 SQL 脚本时报错：Unexpected token '\r'
这是最典型的症状，尤其在 Windows 上用 Navicat 打开从 macOS/Linux 提交的 SQL 文件时出现。Navicat 的 SQL 解析器对 \r\n 容忍度低，遇到孤立的 \r（比如 LF 文件被 Git 错误转成混合换行）会直接中断解析。
- 不是所有 SQL 文件都报错：只有含存储过程、函数或复杂注释的脚本才容易触发，因为这些结构对换行敏感
- Navicat 不会主动修正换行符，也不会提示“检测到 CRLF”，只会静默失败或报语法错误
- 验证方式：用记事本打开该 SQL 文件 → 若状态栏显示“UTF-8 BOM”或“CRLF”，就基本锁定问题来源
Git 配置 core.autocrlf 和 .gitattributes 必须同时生效
只设 git config --global core.autocrlf false 不够，因为团队其他成员可能仍用默认配置，导致仓库里混入 CRLF；只配 .gitattributes 也不行，如果本地 Git 没启用 autocrlf，规则压根不触发。
- 项目根目录必须存在
.gitattributes，内容至少包含：* text=auto eol=lf
- SQL 类文件要显式声明：
*.sql text eol=lf
，否则 Git 可能按二进制处理，跳过换行标准化 - Windows 用户仍需执行：
git config --global core.autocrlf input（不是true），让 Git 在 commit 时把 CRLF 强制转 LF - 改完配置后，必须重置工作区：
git rm --cached -r . && git reset --hard，否则旧换行符缓存仍在
VS Code / 编辑器保存设置和 Navicat 导入行为不一致
你在 VS Code 里把文件设成 LF 并保存，Navicat 却仍报错？因为 Navicat 的「运行 SQL 文件」功能不走编辑器编码流程，它直接读磁盘字节流。如果文件曾被其他工具（如 Notepad++、PowerShell）以 CRLF 保存过，VS Code 的设置无法覆盖历史痕迹。
- VS Code 的
files.eol只影响新创建/另存为的文件，对已存在文件无效 - 真正可靠的做法：在终端用
dos2unix script.sql或sed -i 's/\r$//' script.sql彻底清理 - Navicat 导入时勾选「Remove carriage returns (\r)」选项（位于导入向导「高级」页），这是它唯一内置的换行净化开关
- 若用 Navicat CLI 自动化同步，命令中加
--strip-cr参数，等效于勾选该选项
最容易被忽略的是：Navicat 同步任务里「从文件导入」和「从查询执行」走的是两套解析逻辑——前者严格校验换行，后者由 MySQL 服务端解析，完全不受客户端换行影响。所以临时绕过问题，可以把 SQL 复制进查询窗口执行，但这不能替代规范治理。
