手动导出/导入 connections.ncx 文件是 Mac 与 Windows 跨系统迁移 Navicat 连接最可靠方式；密码不导出需重输，SSH 密钥路径、代理配置、字符集等环境依赖须手动适配。
Mac 到 Windows（或反向）迁移连接，connections.ncx 是唯一可靠路径
navicat 不自动同步连接配置，跨系统迁移时别指望“登录账号就恢复”——navicat cloud 确实能同步连接设置，但前提是两端都登录了同一账号、且已开启同步（默认可能关闭）。而最稳、最可控的方式，就是手动导出/导入 connections.ncx 文件。
实操建议：
- 在旧电脑上：菜单栏 → 文件 → 导出连接 → 选中全部或指定连接 → 保存为
connections.ncx（名字可自定，但后缀必须是.ncx） - 新电脑安装同版本 Navicat（如旧的是 16.3，新装 17.x 可能不兼容导入格式）→ 菜单栏 → 文件 → 导入连接 → 选中该文件
- 注意：所有密码不会被导出，首次连接时需重新输入并勾选“保存密码”，否则下次仍要输
Navicat Cloud 同步失效？检查这三项关键开关
很多人开了云同步却没效果，不是功能坏了，而是三个地方卡住了。
常见错误现象：
- 连接列表在 Mac 上改了，Windows 上还是旧的
- 新建查询片段没出现在另一台设备
- 提示 “Sync is paused” 或 “Not signed in” 却以为已登录
实操建议：
- 确认 Navicat 桌面端右下角状态栏显示 “Synced”，不是 “Syncing…” 或 “Paused”
- 进入 Navicat Cloud Portal（网页端），检查当前设备是否在线、同步范围是否勾选了 “Connections” 和 “Queries”
- macOS 上若用 Apple ID 登录系统，部分用户反馈需在 Navicat 设置中手动退出再重登账号，避免系统级凭据干扰
迁移后连不上数据库？大概率是 SSH 隧道或代理配置没重设
导出的 connections.ncx 里只存连接参数，不存本地 SSH 密钥路径、代理命令、跳板机配置等运行时依赖。Mac 和 Windows 的密钥位置、终端行为、OpenSSH 版本都不同，直接复用常失败。
使用场景：
- 源库在内网，靠 SSH 隧道连（比如通过
jump-server） - 公司强制走 HTTP 代理访问云数据库
- 用了自定义 SSH 命令（如
ssh -i ~/.ssh/prod-key …）
实操建议：
- 导入后双击连接 → 点击 SSH 标签页 → 检查私钥路径是否还存在（Mac 的
~/.ssh/id_rsa在 Windows 上肯定不存在）→ 改为新机器上的对应路径，或重新生成密钥对 - 代理配置同理：Windows 上常用
127.0.0.1:10809，Mac 上可能是127.0.0.1:7890，不能照搬 - 如果用的是 Navicat 内置 SSH 客户端（非系统 ssh），记得测试 “Test Connection” 前先点一下 “Save” 再试，否则修改不生效
从 Navicat 15 升级到 17，连接迁移后为什么部分字段乱码？
这不是迁移问题，是字符集继承逻辑变了。Navicat 15 默认按系统 locale 解析连接字符串，而 17 更严格地依赖数据库服务端声明的 character_set_client 和连接时显式指定的 charset。一旦源连接没设 charset，或设了 latin1 但实际存的是 UTF-8 数据，迁移后就会显示问号或方块。
性能 / 兼容性影响：
- 乱码本身不影响查询执行，但会导致 WHERE 条件匹配失败、ORDER BY 错乱
- 某些老项目用
utf8（MySQL 的阉割版，最大 3 字节），而 Navicat 17 默认倾向utf8mb4，若目标库未启用，会静默退化
实操建议：
- 导入连接后，右键连接 → 编辑连接 → 连接 → 高级 → 手动勾选 “Use Unicode UTF-8 for databases” 并设置
charset=utf8mb4 - 若连的是 MySQL 5.7 以下老库，且无法升级，可改设为
charset=utf8，但务必确认表结构也是utf8，否则仍有风险 - 终极验证：执行
SELECT CHARSET(CURRENT_USER());和SHOW VARIABLES LIKE 'character_set%';，看客户端和连接层是否一致
connections.ncx，也照样连不通。 
