journalctl --list-boots 是唯一能直接列出完整引导时间记录的命令，输出带序号、UTC起止时间及boot ID的真实引导周期，适用于所有systemd系统，且不依赖/var/log/wtmp。
journalctl --list-boots 是唯一能直接列出完整引导时间记录的命令，适用于所有 systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 8+ 等）。它不依赖 /var/log/wtmp，能捕获内核 panic 后重启、硬断电恢复、云平台热迁移等场景，输出带序号、UTC 起止时间、boot ID 的真实引导周期。
查历史引导列表：用 journalctl --list-boots
执行后输出类似：
-2 2026-05-28 09:12:33 UTC—2026-06-05 14:22:11 UTC -1 2026-06-05 14:22:11 UTC—2026-09-28 21:07:44 UTC 0 2026-09-28 21:07:44 UTC—2026-09-29 08:04:12 UTC
其中：
- 负数序号表示历史引导（
-1是上一次，0是当前） - 每行时间范围即该次引导的生命周期，精度到秒
- 默认用 UTC，跨时区比对需注意——别直接和
last reboot的本地时间混着看 - 若只显示最近几次，不是命令失效，而是
/var/log/journal被裁剪或未启用持久化日志
查某次引导的详细日志：用 journalctl -b 加序号
想确认某次异常启动发生了什么？直接按 --list-boots 给出的序号查：
-
journalctl -b -1：查上一次引导的全部日志（含 kernel panic 堆栈） -
journalctl -b 0：查当前引导日志（最常用） -
journalctl -b -2 -u sshd：查倒数第二次引导中sshd服务的启动过程
注意：-b 默认只读内存 journal；若要确保查全，先确认已启用持久化：sudo mkdir -p /var/log/journal 并重启 systemd-journald。
非 systemd 系统只能靠 last reboot 拼凑
Alpine、旧版 Debian 或 OpenRC 系统没有 journalctl，/var/log/wtmp 是唯一结构化来源，但必须接受它的硬伤：
-
last reboot只记录显式调用reboot/shutdown -r的事件，内核崩溃后自动重启、断电恢复、休眠唤醒均无记录 - 输出末尾带
still running才代表该次启动延续至今；若出现(02:15)这类括号时间，说明那次启动已终止 -
last不保证严格倒序，last reboot | head -n 1有时会拿到旧记录，建议加-F（full timestamp）并人工核对日期 - 日志可能被 logrotate 清理，
wtmp文件本身也可能损坏——此时who -b和uptime -s只能告诉你“当前这次”何时开始
别把单点时间命令当列表用
uptime -s、who -b、/proc/uptime 都只返回当前引导的起始时间，不是历史列表：
-
uptime -s输出如2026-09-28 21:07:44，和journalctl --list-boots中序号0的起始时间一致 -
who -b精度只到分钟，且在容器或 utmp 损坏时可能为空；它读的是 init 写入的最早标记，比systemd-analyze time更底层 -
/proc/uptime第一列是秒数，适合脚本计算，但需手动换算：date -d "@$(($(date +%s) - $(awk '{print int($1)}' /proc/uptime)))"
真正需要“列表”，就别绕开 journalctl --list-boots——它的输出格式稳定、语义明确，且 boot ID 可直接用于关联日志范围。其他命令只是补位，不是替代。
