navicat premium 不支持跨平台数据库迁移，需分步处理连接配置复用与异构数据搬运：.ncx 文件受系统密钥aes加密且版本不兼容，须通过菜单导出/导入；ssh/代理配置、密码、字符集、类型映射等均需手动校验与重配。
navicat premium 本身不提供跨平台数据库迁移能力，它只负责连接、查询和传输——真正的“平滑迁移”必须拆解为两件事：连接配置的跨系统复用，以及数据/结构在异构数据库间的可控搬运。直接双击.ncx文件或复制配置目录，90%会失败。
导出导入 connections.ncx 文件必须走菜单路径
connections.ncx 不是普通配置文件，它被 Navicat 用当前系统密钥 AES 加密。Windows 上导出的文件，在 macOS 上双击打开只会报 Invalid connection file 或列表为空。
- 正确操作：旧设备上点菜单栏
文件 → 导出连接，勾选“包含密码”（v16+ 默认不勾），保存为mycons.ncx - 目标设备上不能双击该文件，必须打开 Navicat 后执行
文件 → 导入连接，再选中该文件 - v15 和 v17 的 .ncx 格式不兼容：v17 无法直接加载 v15 导出的文件；若版本差太大，先在旧版中导出，再用新版导入
- macOS 导出的中文连接名在 Windows 上乱码，大概率是 UTF-8 BOM 导致，用 VS Code 打开 .ncx → 右下角设为
UTF-8（无 BOM）→ 保存后再导入
SSH 隧道和代理配置不会随连接一起迁移
导出的 .ncx 文件只存连接参数（host/port/database），不存运行时依赖。Mac 和 Windows 的 SSH 私钥路径、代理端口、OpenSSH 行为完全不同，照搬必挂。
- 导入后务必双击连接 → 切到
SSH标签页 → 检查私钥路径是否存在（~/.ssh/id_rsa在 Windows 上无效）→ 改为新机器路径，或重新生成密钥对 - HTTP 代理设置也要重配：macOS 常用
127.0.0.1:7890，Windows 可能是127.0.0.1:10809，不能直接复制粘贴 -
测试连接成功 ≠ 隧道真通：它只验证 SSH 连通性，不验证数据库认证。要真正确认，得连上后执行一条SELECT 1
跨数据库迁移（如 MySQL → PostgreSQL）不能只靠“数据传输”功能
Navicat 的 数据传输 功能只是搬运工，不解决语义鸿沟。自动类型映射常出错，比如 TINYINT(1) 被转成 boolean，但实际存的是 0/1 数值；DATETIME 和 TIMESTAMP WITH TIME ZONE 的时区处理也不同。
- 务必先在测试环境做全量迁移演练，观察日志里的
Warning行——它们往往预示着数据截断或精度丢失 - 字符集必须显式对齐：MySQL 端连接字符串加
;charset=utf8mb4，PostgreSQL 端确保client_encoding = 'UTF8' - 结构同步前手动检查约束、索引、触发器是否被跳过（Navicat 默认不传自定义函数和存储过程）
- 大表迁移建议分批：在
高级选项里启用“按主键范围分片”，避免单次锁表太久
最容易被忽略的点是密码加密绑定机制——它不是 bug，而是设计。Navicat 对密码的保护逻辑深度耦合操作系统凭证（Windows TPM / macOS Keychain），换设备后即使导入成功，密码字段也必然为空。别指望“导出一次，到处可用”，每次迁移后都得手动补输并保存，这是跨平台复用连接配置不可绕过的一步。
