Windows定时关机全攻略：命令行、任务计划与Python脚本

1. 定时关机这件事，远比你想的有用

很多人第一次冒出“让电脑自己关机”的念头，场景都差不多：晚上挂着下载或者跑渲染，人困得不行，又不想让机器空转一整夜；或者家里小孩抱着电脑看动画片，说好半小时，结果一集接一集停不下来；再或者公司里那批公用机器，下班后总有人忘了关，第二天行政挨个去按电源键。这些琐碎需求堆在一起，就催生了一个特别朴素的问题——能不能让电脑到点自己关掉？

答案当然是可以，而且方法不止一种。电脑设置定时关机这个需求，看起来是个小功能，背后其实牵扯到操作系统调度、命令行参数、脚本编程、任务计划管理好几层东西。Windows 自带shutdown命令，一条参数就能搞定；图形界面里有任务计划程序，适合不想碰命令行的人；再往深了走，用 Python 写几行代码，就能做出带倒计时、带取消、带日志的定制化工具。三种路子覆盖了从“临时用一下”到“长期自动化”的全部场景。

这篇内容适合谁看？如果你只是偶尔想让电脑定时关一次，看第二节的命令行方法就够了，五分钟能上手；如果你管着一批机器，或者想把关机逻辑嵌进自己的自动化流程里，那 Python 那部分和任务计划那部分值得细读；如果你纯粹是想搞明白“为什么我设了定时关机结果没生效”，第四节的问题排查表基本能覆盖九成情况。我会把每种方法的原理、参数、坑点都摊开讲，代码直接能抄，命令直接能跑，不绕弯子。

先说个前提：下面所有操作都基于 Windows 环境，因为这是绝大多数人遇到定时关机需求的平台。macOS 和 Linux 也有对应方案，但思路相通，我会在必要处提一句，不展开。另外，所有命令和代码都建议先在虚拟机或者不重要的机器上试一遍，确认行为符合预期再上生产环境，这是基本习惯。

2. 三条技术路线怎么选：先想清楚你要什么

动手之前先做选择题，比上来就敲命令靠谱得多。定时关机这件事，表面看是“到点执行关机”，但不同场景对“到点”的精度、对“能不能取消”、对“要不要留记录”的要求差别很大。选错路线，后面全是返工。

2.1 命令行方案：快、糙、够用

Windows 自带的shutdown命令是最轻量的入口。它的本质是调用系统关机服务，参数里可以直接指定延迟秒数，比如shutdown -s -t 3600就是一小时之后关机。优势极其明显：不用装任何东西，不用写脚本，打开命令提示符敲一行就完事。适合“今晚挂个下载，两小时后关”这种一次性需求。

但它的短板也很清楚。第一，延迟时间是以秒为单位的相对时间，你没法直接说“今晚十一点半关”，得自己算还有多少秒，算错了就尴尬。第二，命令执行后系统会弹一个倒计时提示框，虽然能加-c参数写自定义提示语，但那个框本身关不掉，有些人觉得碍眼。第三，也是最容易踩的坑——这条命令只在当前会话有效，如果你是通过远程或者脚本调用的，会话一断，关机计划可能就没了。所以它适合临时用，不适合做长期自动化。

2.2 任务计划程序：图形化、可持久、适合批量

任务计划程序是 Windows 里被严重低估的一个组件。它能把任意程序、脚本、命令挂到触发器上，触发器可以是具体时间点、可以是每天重复、可以是开机后延迟、甚至可以是某个事件发生时。用它来做定时关机，好处是计划持久化存在系统里，重启不丢，而且可以精确到“每天 23:30 执行”。

代价是配置步骤多。你得打开任务计划程序、创建基本任务、选触发器类型、填时间、选操作类型、填程序路径和参数、最后还要在属性里勾几个选项（比如“不管用户是否登录都要运行”）。对不熟悉的人来说，这一串操作容易在某个环节填错，然后任务静默失败，你还不知道为什么。所以这条路适合“设一次管很久”的场景，比如公司公用机每天下班自动关，配好之后基本不用再管。

2.3 Python 脚本方案：灵活、可扩展、能嵌进流程

当你需要“关机前先做点别的事”——比如先备份文件、先发个通知、先检查某个进程是否结束——前两种方案就不够用了。这时候 Python 的价值就出来了。用os.system或者subprocess调用系统关机命令只是最基础的一层，真正的灵活性在于你可以围绕关机写一整套逻辑：倒计时显示、中途取消、异常捕获、日志记录、甚至做成一个带界面的小工具。

Python 方案的另一个好处是可移植性强。同一套逻辑稍微改改，在 Linux 上把shutdown -s -t换成shutdown -h +分钟数就能跑。如果你有跨平台需求，或者想把定时关机作为某个更大自动化脚本的一个环节，Python 是唯一合理的选择。缺点是需要一点编程基础，而且得确保目标机器上有 Python 环境——不过现在 Windows 10/11 装 Python 已经很容易了，这个门槛在降低。

三条路线的对比如下，你可以对着自己的需求对号入座：

选型逻辑其实一句话能概括：临时用命令行，长期用任务计划，要定制用 Python。三者不互斥，实际工作中经常混着用——比如用任务计划去调用一个 Python 脚本，脚本里再调 shutdown 命令，各取所长。

3. 命令行实操：一条命令背后的参数门道

shutdown这个命令看着简单，参数其实不少，而且有几个参数的行为跟直觉不太一样。把参数吃透，能省掉很多“为什么没按我想的来”的困惑。

3.1 核心参数逐个拆解

最常用的组合是shutdown -s -t 秒数。-s表示关机（shutdown），-t后面跟延迟秒数，范围是 0 到 315360000（差不多十年），不写-t默认是 0，也就是立即执行。这里有个细节：-t的秒数是从命令执行那一刻开始算的相对时间，不是绝对时间点。所以如果你想让电脑在晚上 11 点关，而现在是下午 3 点，你得算 8 小时等于 28800 秒，敲shutdown -s -t 28800。算错了就关错时间，这是最常见的翻车点。

-a是中止关机，全称 abort。只要倒计时还没走完，执行shutdown -a就能取消。这个参数特别有用，相当于给定时关机加了个“后悔药”。但注意，一旦倒计时结束、系统已经开始关机流程，-a就无效了，所以取消要趁早。

-c是自定义提示语，后面跟一段文字，会显示在关机提示框里。比如shutdown -s -t 600 -c "系统将在10分钟后维护关机，请保存工作"。这段文字有长度限制，大概 512 个字符，超了会被截断。提示语里不能有双引号，否则命令解析会出问题，这是个容易忽略的细节。

-f是强制关闭正在运行的程序，不弹“是否保存”的确认框。默认情况下，如果有程序阻止关机，系统会卡在那里等用户响应。加了-f就直接强关，未保存的数据会丢。这个参数要慎用，除非你确定没有重要工作在进行。

-r是重启而不是关机，-h是休眠，-l是注销当前用户。这几个用得少，但知道有总比不知道强。-r配合-t可以做定时重启，适合需要定期重启清理内存的场景。

还有一个-m参数，可以指定远程机器名，配合域环境下的权限可以做远程关机。这个涉及网络和权限配置，普通单机用户用不上，这里不展开。

3.2 绝对时间怎么设：绕开相对秒数的坑

前面说了-t是相对秒数，那有没有办法直接指定“今晚 23:30 关”？shutdown命令本身不支持绝对时间，但可以用at命令配合，或者更现代的做法是用schtasks创建一次性任务。不过最土也最直接的办法，是在批处理里算时间差。

思路是这样的：用系统变量拿到当前时间，和目标时间做差，算出秒数，再传给shutdown -t。批处理里做时间运算比较别扭，因为时间格式受区域设置影响，%time%出来的可能是15:30:00.12也可能是下午 3:30:00。稳妥的做法是用 PowerShell 来算，一行就能搞定：

$target = Get-Date "23:30" $now = Get-Date $seconds = [int]($target - $now).TotalSeconds if ($seconds -gt 0) { shutdown -s -t $seconds }

这段逻辑很直白：算出目标时间和当前时间的差值，转成秒，如果为正就执行关机。如果目标时间已经过了（差值为负），就不执行，避免立刻关机的意外。这个判断很重要，我见过有人没加判断，结果在 23:31 运行脚本，-t收到一个负数，系统行为不可预期。

3.3 一个容易忽略的权限问题

shutdown命令在普通用户权限下能执行，但有个前提：当前用户得有“关闭系统”的权限。绝大多数个人机器上默认是有的，但在某些受管控的环境里，这个权限可能被策略收走了，执行时会报“拒绝访问”。遇到这种情况，不是命令写错了，是权限不够，需要联系管理员，别在那儿反复试参数。

另外，如果你是通过远程桌面连上去执行关机命令，要注意会话断开的影响。shutdown -s -t的计划是挂在系统服务上的，理论上会话断开不影响倒计时，但如果你用的是某些第三方远程工具，行为可能不一样。稳妥起见，远程场景建议用任务计划程序，那个是系统级的，跟会话无关。

提示：执行shutdown -s -t 秒数后，系统托盘会弹出倒计时提示。如果觉得碍事，可以用-c把提示语改成简短说明，但提示框本身无法隐藏，这是系统行为，没有参数能关掉。

4. 任务计划程序：把定时关机做成“设一次管一年”

任务计划程序的价值在于持久化和精确触发。配好一个每天 23:30 关机的任务，之后机器重启、用户切换都不影响，到点就执行。这对公用机器、下载机、展示机这类场景特别合适。

4.1 从零创建一个关机任务

打开任务计划程序（在开始菜单搜“任务计划程序”就能找到），右侧点“创建基本任务”，然后按向导走。名称随便填，比如“每日定时关机”，描述可以不写。触发器选“每天”，然后填开始日期和时间，比如当天 23:30， recur 每天。操作选“启动程序”，程序或脚本填shutdown，添加参数填-s -t 60，意思是到点后再给 60 秒缓冲，让用户有机会保存。起始于留空即可。

向导走完，任务就建好了，但还没完。右键任务点“属性”，在“常规”选项卡里勾上“不管用户是否登录都要运行”，这样即使没人登录，任务也会执行。同时勾“使用最高权限运行”，避免权限不足导致关机失败。在“条件”选项卡里，把“只有在计算机使用交流电源时才启动此任务”取消勾选，否则笔记本拔了电源任务就不跑了，这个坑很多人踩过。

参数里那个-t 60的缓冲是有讲究的。如果直接-s -t 0，到点瞬间关机，正在写文档的人来不及保存。给 60 秒缓冲，系统会弹提示框，用户看到后可以赶紧存盘，或者执行shutdown -a取消。缓冲时间别设太长，否则“定时关机”变成了“定时提醒”，失去意义。60 到 120 秒是比较合理的区间。

4.2 触发器的进阶玩法

基本任务只支持每天、每周、每月这几种简单触发器。如果你想要更复杂的逻辑，比如“工作日才关，周末不关”，或者“开机后 2 小时关”，就得用“创建任务”而不是“创建基本任务”，然后在触发器里手动配置。

工作日关机的配法：触发器选“每周”，勾选周一到周五，时间填 23:30。这样周末自动跳过，不用手动禁用。开机后延迟关机的配法：触发器选“登录时”或者“启动时”，然后在“延迟任务”里填 2 小时。这个适合那种“开机后跑完一轮任务就关”的场景，比如渲染农场里的节点机。

还有一种比较隐蔽的需求：空闲时关机。触发器里有个“空闲时”选项，配合“空闲持续时间”设置，可以做到“机器闲置 30 分钟后关机”。这个适合办公场景，人走了机器自动关，人回来一动鼠标就取消。但要注意，空闲检测对某些后台程序（比如视频播放、下载）不敏感，可能误判，用之前先测试。

4.3 任务失败怎么查

任务计划程序最让人头疼的地方是“静默失败”——任务显示执行了，但机器没关。排查的第一步是看任务的“上次运行结果”列，那里有个返回码。0x0是成功，0x1是通用错误，0x2是文件未找到（通常是程序路径填错了），0x41301是任务正在运行。如果返回码是0x1，大概率是参数写错了或者权限不够。

第二步是看“历史记录”选项卡，里面会记录每次执行的详细日志，包括启动时间、结束时间、错误信息。如果历史记录是空的，说明没开历史记录功能，得在“操作”菜单里点“启用所有任务历史记录”。开了之后再看，信息会详细很多。

第三步是手动验证。在任务上右键点“运行”，看能不能立即触发关机。如果手动运行能关，但定时不关，问题出在触发器配置上；如果手动运行也不关，问题出在操作配置或权限上。这个二分法能快速定位问题在哪一层。

注意：任务计划程序里配置的关机命令，执行环境跟用户桌面会话是隔离的。也就是说，shutdown -s -t 60弹出的倒计时提示框，在用户桌面上可能看不到。所以缓冲时间到了就直接关，用户没有视觉提示。如果在意这一点，可以在关机前用msg命令发个消息，或者干脆用 Python 脚本自己弹窗。

5. Python 代码实现：把定时关机做成可复用的工具

到了 Python 这一层，重点不再是“怎么调关机命令”，而是“怎么把关机逻辑封装好，让它可靠、可取消、有反馈”。下面这套代码是我实际用过的一个版本，结构不复杂，但把几个关键点都照顾到了。

5.1 基础版：倒计时加取消

先看核心逻辑。用subprocess调系统命令比os.system更可控，因为能拿到返回码、能捕获异常。倒计时用time.sleep分段睡，每睡一秒检查一次是否被取消，这样取消响应及时，不会出现“点了取消还要等十分钟”的尴尬。

import subprocess import time import sys def schedule_shutdown(minutes): seconds = minutes * 60 print(f"将在 {minutes} 分钟后关机，按 Ctrl+C 取消") try: for remaining in range(seconds, 0, -1): mins, secs = divmod(remaining, 60) sys.stdout.write(f"\r倒计时: {mins:02d}:{secs:02d}") sys.stdout.flush() time.sleep(1) subprocess.run(["shutdown", "/s", "/t", "0"], check=True) except KeyboardInterrupt: print("\n已取消关机") subprocess.run(["shutdown", "/a"], check=False)

这段代码有几个设计考虑。第一，用\r回到行首刷新倒计时，而不是每秒打印一行，输出干净。第二，KeyboardInterrupt捕获 Ctrl+C，取消时调shutdown /a兜底，防止之前有残留的关机计划。第三，check=True让subprocess在命令失败时抛异常，而不是静默吞掉。第四，/s/t/a这些参数在 Windows 下用斜杠和横杠都行，但斜杠是原生写法，兼容性更好。

实测下来，这个版本在 Windows 10 和 11 上都正常。唯一要注意的是，如果倒计时期间用户手动执行了别的关机命令，/a会把所有关机计划都取消，包括别人的。这在多用户机器上要留意，单机使用没问题。

5.2 进阶版：绝对时间加日志

基础版是相对时间，实际用的时候经常需要“今晚 23:30 关”。改成绝对时间，逻辑上就是把目标时间和当前时间做差，但要把跨天的情况处理好——如果现在已经是 23:31，目标 23:30 应该理解为明天的 23:30，而不是立刻关机。

from datetime import datetime, timedelta import subprocess import time import logging logging.basicConfig( filename="shutdown.log", level=logging.INFO, format="%(asctime)s - %(message)s" ) def shutdown_at(target_str): now = datetime.now() target = datetime.strptime(target_str, "%H:%M").replace( year=now.year, month=now.month, day=now.day ) if target <= now: target += timedelta(days=1) seconds = int((target - now).total_seconds()) logging.info(f"计划关机时间 {target}，剩余 {seconds} 秒") subprocess.run(["shutdown", "/s", "/t", str(seconds)], check=True) logging.info("关机命令已下发")

这里的关键是if target <= now: target += timedelta(days=1)这一行。没有它，在目标时间已过的情况下会算出负数秒数，shutdown收到负数行为不可预期。加上之后，逻辑变成“如果今天的时间点已过，就定到明天”，符合直觉。

日志那块用logging而不是print，是因为这个脚本很可能被任务计划程序调用，没有控制台窗口，print的输出会丢失。写到文件里，事后能查“到底有没有执行、什么时候执行的”。日志文件路径用相对路径，实际部署时建议改成绝对路径，避免工作目录不同导致日志写到奇怪的地方。

5.3 工程化考量：异常、权限与部署

把脚本当工具用，就得考虑异常情况。最常见的是权限不足——shutdown命令在某些环境下需要管理员权限。检测办法是捕获subprocess.CalledProcessError，看返回码是不是 5（拒绝访问）。如果是，提示用户以管理员身份运行，而不是抛一堆看不懂的堆栈。

另一个是重复执行的问题。如果脚本被意外触发两次，会下发两个关机命令，第二个会覆盖第一个的倒计时。防重的方法是在脚本开头检查是否已有待执行的关机计划，但这个检查在 Windows 上没有特别干净的接口，比较实用的做法是用一个锁文件，脚本启动时检查锁文件是否存在，存在就退出，不存在就创建。脚本正常结束或取消时删掉锁文件。

部署方面，如果只是自己用，直接python shutdown_tool.py 23:30就行。如果要长期跑，建议用任务计划程序调用 Python 脚本，而不是让脚本自己常驻。原因很简单：常驻脚本占资源，而且机器重启后要重新拉起，不如交给系统调度省心。任务计划里程序填python.exe的完整路径，参数填脚本路径加时间参数，起始于填脚本所在目录，这样相对路径的日志文件也能正确写入。

提示：Python 脚本里调用shutdown命令时，参数用列表形式传给subprocess.run，不要拼成一个字符串再shell=True。列表形式能避免路径空格和特殊字符带来的解析问题，也更安全。这是写系统调用脚本的基本习惯。

6. 常见问题与排查：那些让人抓狂的“没关成”

定时关机失败的原因五花八门，但高频的就那么几类。下面这张表是我这些年攒下来的排查清单，按“现象”查“原因”，基本能覆盖大部分情况。

6.1 高频故障速查表

这张表里最值得展开的是第一条。Windows 关机时，如果有程序注册了“阻止关机”的响应（比如未保存的文档、正在进行的安装），系统会弹一个“这些应用阻止关机”的界面，等用户点“仍要关机”或“取消”。如果没人点，倒计时走完后系统会停在那里，不会自动关。这就是“命令执行了但没关成”的最常见原因。解决办法要么加-f强关，要么在关机前用脚本检查并关闭那些程序。强关有丢数据的风险，所以更稳妥的做法是提前几分钟发通知，让用户自己保存。

6.2 几个反直觉的坑

第一个坑：shutdown /a会取消所有关机计划。如果你在测试脚本时，机器上还有别人设的关机计划，一个/a全给取消了。这在共享环境里容易引发矛盾。测试时尽量在独立环境做，或者确认没有其他计划再操作。

第二个坑：任务计划程序的“每天”触发器，在跨时区或夏令时切换时可能偏移。这个在国内不明显，但如果机器时区设置有问题，触发时间会差一小时。排查时先确认系统时区对不对，再看任务的下次运行时间是否合理。

第三个坑：Python 脚本用相对路径写日志，在任务计划里跑会写到系统目录。因为任务计划的工作目录默认是C:\Windows\System32，相对路径的日志文件就跑到那儿去了，普通用户还没权限写，导致日志静默丢失。解决办法是在任务里设置“起始于”为脚本目录，或者脚本里用os.path.dirname(os.path.abspath(__file__))拼绝对路径。

第四个坑：休眠和关机不是一回事。shutdown /h是休眠，机器断电但内存状态写到硬盘，唤醒后恢复现场。有些人想要“省电但保留工作状态”，用休眠比关机合适。但休眠对某些驱动兼容性不好，唤醒后可能蓝屏，用之前先测试。定时任务里如果误把/s写成/h，表现就是“机器黑了但没真关”，容易误判为失败。

6.3 一个实用的自检脚本

与其每次出问题手动排查，不如写个自检脚本，把常见检查项跑一遍。下面这段代码检查三件事：当前是否有待执行的关机计划、当前用户是否有权限、系统是否在交流电源上（笔记本场景）。

import subprocess import ctypes import sys def check_pending_shutdown(): result = subprocess.run( ["shutdown", "/a"], capture_output=True, text=True ) if "没有" in result.stderr or "No" in result.stderr: return False return True def is_admin(): try: return ctypes.windll.shell32.IsUserAnAdmin() != 0 except Exception: return False print(f"管理员权限: {is_admin()}") print(f"有待执行关机计划: {check_pending_shutdown()}")

注意shutdown /a在这里被用来“探测”而不是“取消”——如果当前没有关机计划，它会返回错误信息“没有进行中的关机”，借此判断状态。这个技巧有点取巧，但实测有效。不过要小心，如果确实有计划，这一下就把它取消了。所以这个自检脚本只适合在确认没有重要计划时跑，或者改成用schtasks查询任务状态，更稳妥但代码更长。

7. 把定时关机嵌进更大的自动化流程

单独一个定时关机功能，价值有限。真正有意思的是把它当成一个环节，嵌进更大的自动化流程里。比如下载完成后自动关机、渲染任务结束后自动关机、备份脚本跑完自动关机。这些场景下，关机不是目的，是“任务完成后的收尾动作”。

7.1 任务完成检测加关机

以“下载完成后关机”为例，思路是轮询检测下载进程是否还在运行，进程消失后再触发关机。用 Python 的psutil库能方便地查进程，没有的话用tasklist命令也行。

import subprocess import time def wait_and_shutdown(process_name, check_interval=60): while True: result = subprocess.run( ["tasklist", "/FI", f"IMAGENAME eq {process_name}"], capture_output=True, text=True ) if process_name not in result.stdout: print(f"{process_name} 已结束，准备关机") subprocess.run(["shutdown", "/s", "/t", "60"]) break time.sleep(check_interval)

这段代码每 60 秒查一次进程列表，进程不在了就下发关机命令，留 60 秒缓冲。check_interval别设太短，查进程本身有开销，一分钟一次足够。进程名要写准确，带.exe后缀，大小写不敏感但拼写要对。

这个模式可以套用到很多场景：渲染软件进程名、压缩软件进程名、游戏进程名。核心逻辑都是“等某个标志消失，然后关机”。比定时关机更精准，因为它不依赖预估时间，任务真结束了才关，不会出现“时间到了但任务没跑完”的尴尬。

7.2 关机前的收尾动作

关机前该做什么，取决于你的场景。通用的是三件事：记日志、发通知、留缓冲。记日志是为了事后追溯，发通知是给还在用机器的人一个提醒，留缓冲是给保存工作的时间。

发通知在 Windows 上可以用msg命令，给当前登录用户发消息：

subprocess.run(["msg", "*", "/TIME:60", "系统将在60秒后关机，请保存工作"])

*表示发给所有会话，/TIME:60是消息显示时长。这个命令在家庭版 Windows 上可能不可用，专业版和企业版没问题。如果不可用，退而求其次用 Python 的tkinter弹个窗，虽然土但兼容性好。

留缓冲这块，前面提过-t 60的做法。但如果你用的是 Python 脚本自己控制倒计时，缓冲可以做得更灵活——比如前 50 秒允许取消，最后 10 秒锁定，给用户一个“最后机会”的心理预期。这种细节不影响功能，但影响体验。

7.3 跨平台的一点说明

虽然这篇以 Windows 为主，但提一句跨平台的事，免得有人踩坑。Linux 下关机命令是shutdown -h +分钟数或者shutdown -h 23:30，语法跟 Windows 完全不同，-t在 Linux 下是别的含义。macOS 用sudo shutdown -h +分钟数，需要管理员权限。如果你的脚本要跨平台，别硬编码命令，用platform.system()判断系统类型再分支处理，这是基本操作。

Python 的subprocess在三个平台上行为一致，差异只在调用的命令本身。所以跨平台的关键是把“命令构造”抽成一个函数，按平台返回不同的参数列表，主逻辑不变。这样维护起来清爽，加新平台也容易。

8. 我踩过的几个坑和最后的小建议

说几个实际踩过的坑，都是文档里不会写、但真遇到会卡半天的。

第一个，任务计划程序的“隐藏”选项。创建任务时有个“隐藏”勾选框，勾了之后任务在列表里不显示。我有一次帮人排查“为什么每天中午机器自动重启”，找了半天没找到任务，最后发现是有人建了个隐藏任务。排查时如果怀疑有隐藏计划，用schtasks /query /fo LIST /v能看到全部任务包括隐藏的，比图形界面靠谱。

第二个，shutdown命令的返回码不可靠。命令执行成功返回 0，但返回 0 不代表关机一定会发生——前面说的“程序阻止关机”情况下，命令返回 0，机器却没关。所以别只看返回码，要结合实际现象判断。脚本里如果依赖返回码做后续逻辑，得把这个因素考虑进去。

第三个，倒计时期间系统休眠会导致计时暂停。笔记本合盖休眠，shutdown -t的倒计时不走，唤醒后继续走。这会导致“设了 2 小时后关，结果合盖一晚上，第二天打开才关”。如果场景里涉及休眠，用绝对时间比相对秒数可靠，或者干脆禁用休眠。

最后分享一个小技巧：如果你只是想让机器在某个时间点关一次，又不想记命令参数，可以做个桌面快捷方式，目标填shutdown -s -t 3600 -c "一小时后关机"，双击就执行。改时间就右键属性改参数，比开命令行快。取消的话再做个快捷方式填shutdown -a，两个图标放一起，用起来很顺手。这种土办法在个人机器上效率极高，比装任何第三方工具都轻量。

定时关机这个需求，技术含量不高，但把细节做扎实了，能省很多心。选对路线、算对时间、留好缓冲、做好记录，四件事做到位，基本不会出问题。剩下的就是根据自己场景微调参数，用几次就熟了。