navicat跨平台还原需手动对齐sql文件编码、mysql服务端字符集和连接层初始化命令；必须清理crlf换行、utf-8 bom、windows路径注释，并确保首行含set names utf8mb4。
linux导入windows导出的sql文件时报错：路径注释导致语法错误
navicat在windows导出sql时，常在文件头部或注释里写入c:path o able.sql这类绝对路径。linux版mysql客户端（包括navicat自身）不识别为合法路径分隔符，更不会自动转义或忽略——它会把c:projectsdump.sql当作带转义字符的字符串解析，可能触发unknown character或unclosed quote类报错。
必须手动清理所有Windows风格路径注释：
- 全局搜索替换
-- Source: C:\→-- Source: /home/user/（注意双反斜杠在正则中需转义） - 删除或重写含
\的行，尤其出现在/* */块注释里的路径 - 避免保留
file://C:/...这类URI式写法，Linux下无意义且易被误解析
Navicat Linux版导入时“编码选UTF-8却仍乱码”的根本原因
你看到的「编码下拉菜单」只控制Navicat读取SQL文件字节流时的解码方式，不改变MySQL服务端执行语句时的字符集上下文。即使文件是UTF-8（无BOM），若连接层没执行SET NAMES utf8mb4，MySQL仍按默认latin1或utf8解析，中文字段插入直接报Incorrect string value。
关键操作不是改文件编码，而是对齐三层：
- SQL文件本身：用
dos2unix转LF，VS Code保存为UTF-8 (no BOM) - Navicat连接设置：「高级」页勾选
Use Unicode UTF-8，并在Initial command填SET NAMES utf8mb4; - MySQL服务端：确认
character_set_server和collation_server为utf8mb4，非仅客户端变量
Git同步跨平台SQL脚本时，换行符和大小写引发的静默冲突
Windows用户提交的SQL文件默认带CRLF（
），macOS/Linux默认用LF（
）。Git若未统一配置，同一文件在不同系统上diff显示“整行变更”，实际只是换行符差异。更危险的是大小写：Windows文件系统不区分Users.sql和users.sql，但Git仓库推送到macOS/Linux后，后者只保留一个，且不报错。
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
团队必须强制以下三件事：
- 仓库根目录放
.gitattributes，内容至少含：*.sql text eol=lf - Windows用户执行：
git config --global core.autocrlf false（禁用自动转换） - Navicat导出时关闭「添加时间戳注释」——否则每次导出文件头都变，Git认为全文件改动
SQL Server连接中冒号与逗号引发的“连不上”陷阱
很多人在Navicat填SQL Server主机时写192.168.1.100:1433，看着合理，却死活连不上。SQL Server原生连接协议规定端口必须用逗号分隔，即192.168.1.100,1433。冒号会被客户端网络库误判为IPv6地址分隔符或特殊标记，导致端口号解析失败。
这个细节极难排查，因为错误提示常是泛泛的Connection refused或Network error，而非明确指出分隔符问题：
- 务必用逗号，不是冒号；不要加空格（
192.168.1.100, 1433也不行） - 如果启用了防火墙或云安全组，确保1433端口对客户端IP开放
- 测试前先用
telnet 192.168.1.100 1433确认端口可达，排除网络层问题
最麻烦的从来不是某一个分隔符，而是多个层级的分隔符同时存在：SQL文件里的Windows路径、Git的换行符策略、Navicat连接字符串的端口分隔、甚至CSV导出时的字段分隔符——它们各自独立生效，又相互影响。处理时不能只盯一个点，得按「文件内容→传输工具→客户端解析→服务端执行」链路逐层验证。
