reboot本质是快捷命令，默认委托shutdown执行，而shutdown才是安全可控的关机/重启协调器；systemctl reboot才是现代systemd系统的标准推荐方式。
reboot 和 shutdown 本质不是一回事
reboot 是个快捷命令，底层调用 reboot(2) 系统调用，但默认行为其实是“悄悄委托”给 shutdown -r now 执行——除非加了 -f（force）；而 shutdown 是真正的安全关机/重启协调器，会发广播、拒绝新登录、按顺序终止服务。
这意味着：reboot 看似简单，实则依赖当前系统状态和 systemd/init 环境；shutdown -r now 才是可预期、可审计、符合运维规范的操作。
- 普通用户执行
reboot很可能被拒绝（没权限调用systemd-logind或polkit规则）；shutdown -r now同样需要 root 权限，但报错更明确 - 在容器或云主机里，
reboot -f可能直接触发宿主机硬重置，而非重启容器内进程——这根本不是“重启系统”，只是强行断电再上电 -
shutdown生成的记录会写入/var/log/wtmp和journald，reboot -w虽然也写日志，但不触发实际动作，容易误判为“已执行”
什么时候必须用 shutdown -r 而不是 reboot
当你需要留痕、需通知他人、或操作涉及生产服务时，shutdown -r 是唯一合理选择。比如滚动升级前发广播、灰度重启某台 DB 服务器、或者配合监控系统做事件对齐。
shutdown 的 TIME 参数不是摆设：它会在倒计时前 5 分钟自动创建 /run/nologin 阻止新登录，并广播消息到所有 tty —— 这些动作 reboot 完全不提供。
-
shutdown -r +10 "DB主从切换中，请勿提交事务"：10 分钟后重启，所有人终端立刻看到提示 -
shutdown -r 2026-02-18T20:00:00：指定绝对时间（需 systemd 支持），适合排期维护窗口 - 执行后想反悔？立刻
shutdown -c取消，reboot没有等效机制
reboot -f 不是“快一点”，而是“绕过一切”
reboot -f 直接触发内核级重启，跳过用户空间服务停止流程、不写关机日志、不通知 systemd、甚至不 sync 磁盘缓存。它等价于长按物理电源键 —— 仅适用于系统完全卡死、ssh 失联、且你确定磁盘无重要未刷写数据的极端场景。
- 在使用 ext4 + data=ordered 的服务器上，
reboot -f可能导致文件系统 inconsistency，下次启动要跑e2fsck - Kubernetes 节点若用
reboot -f重启，kubelet 来不及上报 “NotReady”，Pod 驱逐延迟，可能引发短时双主或脑裂 - 云平台（如阿里云 ECS、AWS EC2）控制台显示“正在重启”，但底层是通过 ACPI 信号触发，此时
reboot -f反而可能干扰云代理行为
systemctl reboot 其实才是现代标准答案
如果你用的是 systemd（几乎所有主流发行版默认），systemctl reboot 才是推荐入口。它和 shutdown -r now 底层走同一套逻辑，但语义更清晰、集成度更高，且支持 --no-wall、--no-block 等精细控制。
-
systemctl reboot --no-wall：重启但不广播，适合自动化脚本静默执行 -
systemctl reboot --no-block：发起重启后立即返回 shell，不等待完成（类似后台任务） - 对比
reboot，systemctl reboot会检查DefaultTimeoutStopSec等配置，对慢停服务更友好
真正容易被忽略的点是：很多老文档教 init 6 或 telinit 6，但在 systemd 系统上它们只是软链接到 systemctl，还多一层兼容层开销——没必要绕路。
