journalctl --list-boots 是最可靠的历史启动时间列表来源，支持 systemd 系统，可识别内核 panic、硬重启、热迁移等异常启动，输出带序号、utc 起止时间及 boot id 的完整周期。
journalctl --list-boots 是最可靠的历史启动时间列表来源
如果你的系统是 systemd（Ubuntu 16.04+、CentOS 7+、Debian 8+ 等主流发行版），journalctl --list-boots 就是首选。它不依赖 /var/log/wtmp，能识别内核 panic 后自动重启、硬重启、云平台热迁移等异常启动，输出带序号、起止时间（精度到秒）和 boot ID 的完整周期。
每行格式类似：-2 2026-05-28 09:12:33 UTC—2026-06-05 14:22:11 UTC，其中负数序号表示历史启动（-1 是上一次，0 是当前），时间范围即该次启动的生命周期。
- 若
/var/log/journal为空或被清理过，journalctl --list-boots只显示最近几次——这不是命令失效，而是日志被裁剪了 - 默认用 UTC 时间，跨时区比对需注意和
last reboot的本地时区差异 - 想查某次启动的详细日志？用
journalctl -b -1（倒数第二次）、journalctl -b 0（当前）
last reboot 只能查“主动发起的重启”
last reboot 读取的是 /var/log/wtmp 中标记为 reboot 的记录，本质是“用户或脚本显式调用 reboot/shutdown -r 后触发的事件”。它对以下情况无记录：
- 内核 panic 后自动重启
- 电源断电后恢复供电的硬启动
- 某些容器或云平台热迁移后的启动（未触发传统 reboot 流程）
- 从休眠（suspend-to-RAM）恢复，systemd 不会写入 reboot 条目
输出示例：reboot system boot 5.15.0-125-generic Thu Jun 5 14:22 still running，末尾 still running 表示该次启动延续至今；时间字段是本地时区，不是 UTC。
uptime -s 和 who -b 只返回最后一次启动时间
这两个命令本质是单点查询，不是列表工具：
-
uptime -s从内核启动时间戳推算，输出如2026-06-05 14:22:11，和journalctl --list-boots中序号0的起始时间一致 -
who -b从 utmp 初始化时刻读取，输出如system boot 2026-06-05 14:22，精度只到分钟，部分老旧系统或容器环境可能缺失 utmp 条目，返回空 - 它们快、轻量，但无法回溯——你执行一次，永远只得到当前这次启动的时间
没有 systemd 的系统只能靠 last + 日志人工拼接
如果用的是 SysV init 或 OpenRC（如 Alpine、旧版 Debian），journalctl 不可用，/var/log/wtmp 就是唯一结构化来源，但必须接受它的局限性：
- 运行
last reboot | head -20查最近 20 条 reboot 记录 - 补查
last shutdown对应时间，再结合/var/log/messages或/var/log/syslog中的关键词（如reboot、kernel: reboot:）交叉验证 - 注意：
last不保证严格倒序，中间可能有缺失；last reboot | tail -n +2拼“列表”不可靠
真正要还原完整重启脉络，得把 last 输出、日志关键词、硬件监控（如 IPMI）甚至运维操作记录一起看——没有银弹，只有多源印证。
