答案：必须编辑root的crontab，因普通用户无权调用关机接口，sudo在cron中不生效；需用绝对路径/sbin/shutdown -h +0并重定向日志，配合systemctl验证服务与规则。
直接用 cron 配合 /sbin/shutdown 是最稳妥、最通用的做法，其他方式要么权限受限，要么过度复杂。
为什么必须编辑 root 的 crontab
普通用户没有调用关机接口的权限，shutdown -h 会直接拒绝执行。即使你用 sudo 写进普通用户的 crontab，cron 环境下 sudo 默认不读取 tty 密码，会卡住或静默失败。
- 必须运行
sudo crontab -e，编辑的是 root 用户的定时任务表 -
/etc/crontab虽然也支持指定用户字段，但容易因格式错误导致整条规则失效，不推荐新手用 - 别试图在用户 crontab 里写
sudo shutdown—— 它不会弹密码框，也不会继承你的 sudo 权限缓存
crontab 时间格式和 shutdown 参数怎么配才可靠
常见错误是把 now 和 +0 混用，或者漏掉绝对路径。cron 环境 PATH 极窄，只认 /usr/bin 和 /bin，而 shutdown 在 /sbin 下。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 时间字段写成
30 23 * * *表示每天 23:30 执行；0 2 * * 6表示每周六凌晨 2:00 - 命令部分必须用绝对路径：
/sbin/shutdown -h +0，而不是shutdown -h now -
+0比now更可靠：部分发行版（如某些 Alpine 或最小化镜像）的 cron 环境不识别now关键字 - 加日志重定向能帮你快速定位失败原因：
/sbin/shutdown -h +0 >> /var/log/shutdown.log 2>&1
如何验证 cron 是否真在运行且规则已生效
很多人改完就以为 OK，结果到了时间没关机，其实是 cron 服务没开，或者规则语法错导致整行被跳过。
- 先确认服务状态：
systemctl is-active cron（或crond，取决于发行版） - 查看当前生效规则：
sudo crontab -l，注意输出里有没有你刚加的那行 - 手动触发测试（别真关机）：
sudo /sbin/shutdown -h +1，看是否 1 分钟后响应；再立刻sudo shutdown -c中止 - 检查 cron 日志：
journalctl -u cron -n 20，找是否有 “command not found” 或 “permission denied”
at 和 systemd timer 什么时候该考虑
它们不是不能用，而是适用场景很窄，强行套用反而增加维护成本。
-
at只适合单次、明确日期+时间的任务（比如“明天上午 10:15 关机做硬件维护”），且机器重启后任务丢失 —— 不适合日常定时关机 -
systemd timer需要写两个文件（.service + .timer），还要systemctl daemon-reload，对关机这种简单动作纯属杀鸡用牛刀 - 如果系统连
atd或systemd都没启用（比如嵌入式 BusyBox 环境），cron几乎是唯一选择
真正容易被忽略的是环境差异：有些容器镜像或精简系统默认不装 cron，有些则默认禁用 atd；/sbin/shutdown 在某些发行版里被软链接到 systemctl，但行为一致。动手前先 which shutdown 和 systemctl list-units --type=timer | grep cron 确认基础组件就位，比事后排查快得多。
