Navicat不识别UNC路径或映射盘符，因其所有版本仅接受本地绝对路径，无UNC解析逻辑，导致静默生成0KB文件；需改用本地中转目录+robocopy/rsync同步。
备份路径填了 UNC 或映射盘符，Navicat 根本不识别
Navicat 所有版本（Windows/macOS/iOS）底层只接受本地绝对路径，对 \servershareackup.sql 或 Z:ackup.sql 这类路径完全无解析逻辑。它不会报错，也不会提示“路径无效”，而是静默跳过写入——结果就是生成一个 0KB 的空文件。
验证方法很简单：把同样路径粘贴进 CMD，执行 echo test > \servershare est.txt，如果失败，说明操作系统层就不通；哪怕 Navicat GUI 里“测试连接”成功，也不代表文件能写进去——连接测试不涉及磁盘 I/O。
- UNC 路径在非交互式上下文（如计划任务、后台服务）中通常不可见
- 映射盘符（如 Z:）依赖用户登录会话，定时任务常以系统上下文运行，Z: 根本不存在
- 路径中含中文、空格、
(、)、&等字符，也会导致底层mysqldump启动失败，但 Navicat 不暴露 stderr
备份目标目录没有写权限，或被 OneDrive/Google Drive 拦截
即使路径是本地的（如 C:ackupmydb.sql），若当前运行 Navicat 的用户对该目录无写权限，或该目录位于 OneDrive、Google Drive、iCloud 同步文件夹内，文件可能被拦截、延迟写入，或仅创建空句柄。
常见现象是：任务日志显示“备份完成”，但打开目录发现文件大小为 0 字节；用资源管理器刷新几次后文件才“突然出现”。这是因为同步客户端接管了文件句柄，阻塞了实际写入。
- 临时目录和备份目标都应设在纯本地 NTFS 分区（如
D: avicat_backups），避开任何云同步路径 - 右键目标目录 → 属性 → 安全 → 确认当前用户有“完全控制”权限
- Windows 下禁用 NTFS 压缩：属性 → 高级 → 取消勾选“压缩此驱动器以节省空间”
mysqldump 子进程崩溃或被截断，Navicat 未捕获错误输出
Navicat 的 GUI 封装层依赖 mysqldump 进程的标准输出来判断进度和成功与否。一旦 mysqldump 因权限、超时、max_allowed_packet 不足等原因提前退出，而 Navicat 没读到完整输出，就可能只留下空文件。
典型触发场景包括：导出含大量 BLOB 的表、DEFINER 用户不存在、SQL mode 不兼容（如 NO_ZERO_DATE）、或数据库端 wait_timeout 过短导致连接中途断开。
- 检查 Navicat 日志（菜单栏 → 工具 → 日志 → 查看日志），搜索
Can't create/write to file、Lost connection、Errcode: 13 - 手动在命令行跑等效命令验证，例如：
mysqldump -h127.0.0.1 -P3306 -uroot -p --single-transaction mydb > C: emp est.sql - 若命令行也失败，问题不在 Navicat，而在数据库配置或用户权限
计划任务没保存批处理，或没填数据库密码
Navicat 定时备份本质是“批处理任务 + 系统调度”。如果新建完备份动作后没先点“保存”，直接去设 Schedule，任务根本不会注册到 Automation 系统中；或者连接密码没在 Connection 属性里显式保存，计划任务运行时拿不到凭据，mysqldump 就会卡在认证阶段，最终产出空文件。
- 务必在 Connection 设置里勾选“保存密码”，再点 OK 确认保存
- Automation 中新建 Batch Job 后，必须先执行“保存”，再右键该任务 → Set Task Schedule
- Windows 下打开任务计划程序，找到以
Navicat Export Task开头的任务，确认其“常规”页中勾选了Run whether user is logged on or not
