Mac下Navicat数据传输后台中断的根本原因是macOS系统级睡眠策略、App Nap机制及TCP保活缺失三重叠加；必须用caffeinate -s强制阻止系统休眠，并配合pmset调优与launchd plist修正，否则传输必卡死。
Mac 下 Navicat 数据传输任务无法在后台保持唤醒，根本原因不是 Navicat 本身没“努力”，而是 macOS 主动冻结了它——系统睡眠策略、App Nap、TCP 连接保活缺失三者叠加，导致传输中途断连或卡死。
为什么 caffeinate 不加 -s 选项就无效？
Navicat 的数据传输（如「数据传输」向导或「批处理作业」）本质是前台 GUI 启动的子进程，不带 -s（system sleep prevention）的 caffeinate 只能阻止 Display Sleep 和 UserIdleSleep，但无法抑制 System Sleep。一旦触发内核级挂起，TCP 连接被冻结，mysqldump 或 mysql 子进程收不到 ACK，超时后静默中断，Navicat 界面可能还显示“正在传输”，实际已卡住。
-
caffeinate -i rsync ...或caffeinate -d ...都不能防止系统休眠，仅适用于临时防屏幕关闭 - 必须用
caffeinate -s -t 7200（-s 是关键，-t 是保险时限）包裹整个 Navicat 启动命令 - 若通过
open -a Navicat启动，需改用caffeinate -s -t 7200 /Applications/Navicat\ Premium.app/Contents/MacOS/Navicat，否则断言不继承到子进程
Navicat 自带的「自动同步」在 Mac 上为何默认失效？
Mac 版 Navicat 没有常驻后台服务（不像 Windows 的 NavicatMonitorService），它的「计划任务」依赖 launchd 加载 plist，而默认 plist 不带 KeepAlive 或 StartCalendarInterval，且未声明 ProcessType = Interactive，导致系统在用户登出或进入低功耗状态后直接卸载该 job。
- 真实路径通常是
~/Library/LaunchAgents/com.premiumsoft.navicat.*.plist，用launchctl list | grep navicat查是否加载 - 手动编辑 plist 后必须运行
launchctl unload -w+launchctl load -w才生效，仅改文件不触发重载 - 即使加载成功，若 plist 中没设
AbandonProcessGroup
外接设备或远程连接下，pmset 哪些参数必须检查？
USB-C 扩展坞、雷电硬盘、远程 MySQL（SSH 隧道）等场景会触发 macOS 的 DarkWake 行为，此时 pmset -g assertions 显示 PreventSystemSleep 为 0，但实际已进入浅层休眠——tcpkeepalive 默认关闭，SSH 连接断开，Navicat 就卡在“正在连接”或“等待响应”。
- 运行
sudo pmset -a tcpkeepalive 1强制启用 TCP 心跳（需管理员权限） - 检查
pmset -g custom中disksleep是否为 0；若为非零值（如 10），外接硬盘可能在空闲 10 分钟后休眠，导致写入失败 - 若用 SSH 隧道，确保
ServerAliveInterval 30和ServerAliveCountMax 3已写入~/.ssh/config，否则隧道静默断开 -
powernap必须禁用：sudo pmset -a powernap 0，否则系统会在后台自动触发网络唤醒+休眠循环
真正可靠的方案不是让 Navicat “扛住休眠”，而是让它根本不进入休眠影响范围：用 caffeinate -s 启动 + 关闭所有干扰性电源子策略 + 避免依赖 GUI 会话生命周期。任何试图靠修改 Navicat 设置绕过系统电源管理的行为，最终都会在 USB-C 扩展坞、远程隧道或夜间长传输中暴露出来。
