Navicat 16 不支持跨平台共用 .nsx 自动化脚本，因 .nsx 是含Windows路径、加密凭据和UI状态的二进制文件，macOS 的 navicatCLI 不识别 -sync 参数；唯一可共用的是纯 SQL + 显式连接参数 + 原生命令行工具链。
navicat 16 本身不支持跨平台共用自动化脚本（如 .nsx 同步任务、.sql 查询脚本的执行上下文），因为它的自动化能力严重依赖客户端运行时环境——windows 有 navigator.exe，macos 没有等效可执行入口；脚本中硬编码的路径、字符集、ssh 配置、甚至时间戳格式都随系统行为变化。所谓“共用”，必须剥离 navicat 自身的平台绑定逻辑，只保留纯 sql 和结构定义。
为什么 .nsx 文件不能直接在 Mac 上运行
Navicat 的 .nsx 是二进制序列化文件，包含连接句柄、UI 状态、本地路径缓存和加密凭据引用，不是可移植脚本。macOS 版 Navicat 16 自带的 navicatCLI 工具根本不识别 -sync 参数，调用会直接报错 Unknown option: -sync 或静默退出。官方从未承诺 .nsx 跨平台兼容，v16.2 之后 macOS 端已彻底移除对旧版同步协议的支持。
- Windows 下能跑通：
"C:\Program Files\PremiumSoft\Navicat Premium 16\navigator.exe" -sync "D:\tasks\sync_prod_to_test.nsx" - macOS 下等效命令不存在；
/Applications/Navicat\ Premium.app/Contents/MacOS/navicatCLI -sync会返回Invalid argument - 即使强行用 Wine 或 CrossOver 运行 Windows 版
navigator.exe，也会因缺少 TPM 密钥访问权限而卡在连接加载阶段
真正可共用的只有纯文本 SQL + 显式连接参数
把自动化逻辑从 Navicat UI 中“抽离”出来，是唯一可靠路径。核心原则：不依赖 .nsx、不依赖 Navicat 进程，只用标准命令行工具 + 可读配置。
- 用
mysqldump/pg_dump替代「数据传输」：导出为.sql或.csv，所有平台都能用mysql/psql执行 - 连接信息不藏在
.nsx里，改用环境变量或配置文件管理：DB_HOST=192.168.1.100 DB_USER=admin DB_PASS=xxx ./sync.sh - 增量逻辑写死在 SQL 里，而不是靠 Navicat 的「自定义查询」弹窗：
INSERT INTO target_table SELECT * FROM source_table WHERE updated_at > '2026-06-01'; - SSH 隧道统一用
ssh -L 3307:localhost:3306 user@jump-host建立，Navicat 连接目标设为127.0.0.1:3307，避免路径和密钥格式差异
Mac 和 Win 共享查询脚本时最容易踩的坑
表面看都是 .sql 文件，但实际执行效果常不一致，问题不在 SQL 本身，而在 Navicat 如何解析和提交它。
- 换行符：Windows 用
\r\n，macOS 用\n；Navicat for MySQL 16 在 macOS 上遇到\r\n可能截断注释或误判语句边界 - 路径分隔符：SQL 里若写
LOAD DATA INFILE 'C:\data\users.csv'，Mac 直接报错；必须改用正斜杠且相对路径：LOAD DATA INFILE 'data/users.csv' - 字符集隐式转换：Windows 客户端默认用
GBK解析文件，Mac 用UTF-8；含中文的 SQL 若未声明SET NAMES utf8mb4，Mac 上可能显示乱码或插入失败 - 查询历史不共享：你在 Win 上双击运行的脚本，不会自动出现在 Mac 的「查询历史」里；别指望靠同步盘复制
LogHistory.txt或query_history.db—— 格式互不兼容
跨平台共用的本质，是放弃 Navicat 的“一体化自动化”幻觉，回归数据库原生工具链。真正的可移植性，来自你手写的那几行 mysql -h $DB_HOST -u $DB_USER -p$DB_PASS database_name ，而不是双击一个图标。任何试图绕过这点去“适配 Navicat”的方案，最终都会卡在密钥派生、路径绑定或 UI 状态序列化上。
