Navicat定时任务休眠唤醒后“错过”本质是调度周期被跳过，因NavicatMonitorService休眠时被终止且不监听唤醒事件，也不重载时间表，仅按原轮询节奏继续执行。
休眠唤醒后任务“错过”不是延迟，而是根本没触发
Navicat 定时任务在休眠唤醒后出现“错过”，本质不是执行慢了，而是整个调度周期被跳过——因为 NavicatMonitorService 在休眠（S4）过程中被强制终止，且唤醒后不会自动恢复。它不监听系统唤醒事件，也不重载任务时间表，只会继续从上次轮询时间点往后算，中间空档直接丢失。
Windows 任务计划程序的“唤醒”开关只管启动，不管 Navicat 内部逻辑
即使你在任务属性里勾选了「唤醒计算机以运行此任务」，这个动作只负责把 navicatcmd.exe 拉起来一次；但 Navicat 自身的轮询调度器（每分钟检查一次时间表）并不会因这次唤醒而补跑错过的任务。它仍按原节奏走，比如本该凌晨2:00执行的任务，若电脑在1:55进入休眠、3:10唤醒，那2:00那次就永远没了。
- 「唤醒计算机」仅对当前注册的单次任务生效，不是全局调度补偿机制
- 若任务配置为“每天固定时间”，且触发时刻系统处于休眠态，Windows 任务计划程序默认不重试，也不会延后执行
-
navicatcmd.exe --run "task-id"是一次性命令，执行完即退出，不维持任何状态或监听后续时间点
真正能补漏的只有外部脚本 + 显式时间判断
想让任务在唤醒后“追平”错过的执行点，必须绕过 Navicat 内置调度器，改用自定义逻辑判断当前时间是否已跨过预定时刻。例如：用 PowerShell 脚本检查系统时间是否已过当日 2:00，且本地无当日备份文件，则立即调用 navicatcmd.exe 执行。
- 不能依赖
--run的参数自动识别“该不该补”，它只认 task-id，不认业务语义 - 备份路径需用绝对路径，且文件名含
%date%或$(Get-Date -Format 'yyyyMMdd')避免覆盖 - 若用批处理，
timeout /t 60类等待不可靠——唤醒后系统可能还在加载驱动或网络，建议加ping -n 3 127.0.0.1 >nul等基础服务就绪
最常被忽略的细节：休眠残留导致服务无法及时响应
即使你禁用了休眠，只要之前启用了快速启动（Fast Startup），关机时仍会保存内核会话镜像，下次开机加载后 NavicatMonitorService 可能卡在“启动中”状态长达数十秒——这段时间内所有轮询都失效。这不是日志里能轻易看到的问题，但会导致连续数天的首次备份失败。
每次系统更新后，务必再跑一次 powercfg /a 确认输出中彻底没有 “Hibernate” 字样；同时检查服务管理器里 NavicatMonitorService 的启动类型是否为「自动」而非「手动」——它只在用户登录后由 Navicat 主程序尝试启动，无人值守场景下毫无意义。
