拿五台机子对账：任务计划里藏了个定时重启，Bios的快速启动悄悄把它吞了

先说结论：如果你用任务计划程序设了定时重启或定时清理，但机器实际没按点执行，先别怪脚本，去Bios里看一眼 Fast Boot（快速启动）是不是开着的。我拿五台机子蹲了一周，才把这条链路捋清楚。

事情起于上个月给自己那台常开的小主机设了个凌晨四点自动重启，脚本写得很干净，shutdown /r /t 0，触发条件、电源设置、唤醒定时器全核过一遍，schtasks /query /v 输出里 Last Run Result 是 0x0，日志也显示任务确实跑了。但第二天起来 uptime 还是三天。

我先怀疑是电源策略把唤醒拦了，翻 powercfg /waketimers 没发现异常；又怀疑是快速启动把关机搞成了休眠，powercfg /a 里「休眠」那一项确实可用。关键一步：我对比了五台机子——

• A、B 两台开了 Fast Boot，任务计划触发后系统日志里只有 Kernel-Boot 的 resume 记录，没有完整的 boot 流程；
• C、D 两台关了 Fast Boot，同样的脚本每次准点重启；
• E 台开了 Fast Boot 但没开休眠，表现和 C、D 一致。

也就是说，Fast Boot 只有在休眠文件（hiberfil.sys）存在时才把「重启」偷偷变成「休眠+恢复」，任务计划那边看着成功，实际没走完整引导。验证方法很简单：跑完任务后看 systeminfo 里的 System Boot Time，如果还是旧时间，就是没真重启。

我的处理是：保留 Fast Boot 的开机速度，但把计划任务的触发条件从「重启」改成先 shutdown /s /t 0 再配合主板 RTC 唤醒，或者干脆在跑清理脚本前先 powercfg /h off 关掉休眠、执行完再开回来。后者我实测对开机速度影响有限，因为 Fast Boot 主要吃的是驱动初始化缓存，不是休眠文件本身。

另外提醒一点：定时清理 Temp 的脚本如果依赖「重启后首次登录」触发，在 Fast Boot 下这个触发点可能根本不出现，我拿 B 台复现了两次，日志里连 Logon 事件都没有。所以脚本里最好加个时间戳校验，跑完写一行记录到独立日志，别只信任务计划的 Last Run Result。

顺带说一句，软领那种一键自动优化确实省事，但它不会告诉你 Fast Boot 和计划任务之间的这层关系，手动党的价值就在这——每一层都能自己拆开看。

想问问各位：你们设定时任务时，是习惯关休眠保确定性，还是留着 Fast Boot 换开机速度？有没有人碰到过 RTC 唤醒在 Fast Boot 下失效的情况？