navicat 连接配置无法真正跨平台统一，因 connections.ncx 文件不兼容不同系统，密码、ssh 路径及编码行为存在差异；需通过内置导出/导入功能（v15+ 强制 utf-8）、手动重设密码与 ssh 参数（路径、代理命令）来适配目标环境。
不能真正“统一”连接配置，因为 navicat 的 connections.ncx 文件本身不跨平台兼容，且密码、ssh 路径、编码行为在不同系统上表现不一致。唯一可行的路径是：用 .ncx 文件作为中间载体 + 手动适配关键环境项。
导出和导入必须走 Navicat 内置功能，别碰 config 目录
直接复制 connections.ncx 文件到另一台电脑（尤其是跨系统）大概率报 invalid connection file 或连接列表为空。原因在于：
- Windows 版依赖注册表写入部分元数据，macOS 依赖
~/Library/Preferences/com.premiumsoft.navicat.*.plist -
.ncx文件虽为 XML 格式，但含加密字段（如密码占位符）和平台相关序列化逻辑 - Navicat v15+ 默认导出不包含密码；v16 起需手动勾选「导出时包含密码」，且该选项仅对当前设备有效
正确做法：
- 旧设备：菜单栏 →
文件→导出连接→ 勾选「导出时包含密码」（如果版本支持）→ 保存为my-connections.ncx - 新设备：安装**同主版本** Navicat（如都是 v16.x，不要 v16 → v17）→
文件→导入连接→ 选中该.ncx文件 - 导入后所有连接密码字段为空或星号，必须逐个点开 →
编辑连接→ 在「常规」或「SSH」页重新输入密码 → 点测试连接
SSH 密钥路径和代理命令必须重设
.ncx 文件只存连接参数（主机、端口、用户），不存运行时本地依赖。Mac 和 Windows 的 SSH 行为差异极大：
- macOS 默认密钥路径是
~/.ssh/id_rsa，Windows 上可能是C:\Users\XXX\.ssh\id_rsa或 PuTTY 的.ppk格式 - OpenSSH 版本不同（macOS 自带较新，Windows 可能用 Git Bash 或 WSL 的旧版），导致
ProxyCommand语法不兼容 - 跳板机（Bastion Host）配置若含绝对路径或 shell 命令（如
nc -X connect -x proxy:8080 %h %p），在另一系统上常直接失败
实操建议：
- 导出前，在旧设备上记下每个连接的 SSH 设置：私钥路径、用户名、端口、代理命令全文
- 导入后，进每个连接的
SSH页，手动填入目标系统的对应路径（如 macOS 改成/Users/xxx/.ssh/id_rsa，Windows 改成C:\Users\xxx\.ssh\id_rsa） - 代理命令中避免硬编码路径，改用相对路径或环境变量（如
nc -X connect -x $PROXY_HOST:$PROXY_PORT %h %p），并在系统级 shell 配置中定义PROXY_HOST
中文连接名乱码？UTF-8 是唯一安全编码
Windows 旧版 Navicat（v12–v14）默认用 GBK 解析连接名，macOS 始终用 UTF-8。.ncx 文件本身是 UTF-8 编码，但 Windows 上读取时可能误判——导致中文名显示为方块或截断。
解决方法很直接：
- 确保两端都使用 Navicat v15 或更高版本（v15+ 统一强制 UTF-8 处理
.ncx） - 导出前，在 Windows 上把连接名改成纯英文（如
prod_mysql_sh），导入后再手动改回中文（此时编辑框可正常输入 UTF-8） - 不要依赖「云同步」修复乱码：Navicat Cloud 同步也受客户端编码策略影响，v14 及以下版本同步后仍可能错乱
真正麻烦的不是导出导入动作本身，而是那些藏在 SSH 配置、密码绑定机制和编码隐式转换里的细节。哪怕 .ncx 文件能成功加载，只要密钥路径错一位、代理命令少一个空格、或者密码没重输，连接就卡在「测试失败」——而错误提示往往只写「Connection refused」，看不出是哪一层崩了。
