journalctl --list-boots 是最可靠的历史启动时间列表来源，输出带序号、起止时间（精度到秒）和boot id的完整启动周期，支持ubuntu 16.04+、centos 7+等systemd系统，不依赖wtmp且能识别异常重启。
journalctl --list-boots 是最可靠的历史启动时间列表来源
systemd 系统（Ubuntu 16.04+、CentOS 7+、Debian 8+ 等主流发行版）直接支持 journalctl --list-boots，输出带序号、起止时间的完整启动周期列表，精度到秒，且自动关联每次 boot 的日志范围。
- 输出中每行格式为：
-2 2026-05-28 09:12:33 UTC—2026-06-05 14:22:11 UTC，其中负数序号表示历史启动（-1是上一次，0是当前），时间范围即该次启动的生命周期 - 若系统未启用持久化 journal（
/var/log/journal为空或被清理），则只显示最近几次启动——这不是命令失效，而是日志被裁剪了 - 不依赖
/var/log/wtmp，不受last的 utmp 记录策略影响，比如异常断电后未正常 shutdown 的启动也能被识别
last reboot 只能查重启事件，不能反映所有启动
last reboot 读取的是 /var/log/wtmp 中标记为 reboot 的记录，它只记录“主动发起的重启”，对内核 panic 后自动重启、硬重启、或某些云平台热迁移后的启动可能无记录。
- 输出示例：
reboot system boot 5.15.0-125-generic Thu Jun 5 14:22 still running，注意末尾的still running表示该次启动延续至今 - 若某次启动没触发
reboot事件（比如从休眠恢复、或 systemd 检测到内核崩溃后 silent restart），last reboot就不会出现对应条目 - 时间字段是本地时区，而
journalctl --list-boots默认用 UTC，跨时区比对需留意
uptime -s 和 who -b 只返回最后一次启动时间，不是“列表”
这两个命令本质是单点查询：一个从内核启动时间戳推算，一个从 utmp 初始化时刻读取。它们快、轻量，但无法回溯——你执行 uptime -s 得到的永远只是当前这次启动的开始时间，和历史无关。
-
uptime -s输出如2026-06-05 14:22:11，和journalctl --list-boots中序号0的起始时间一致 -
who -b输出如system boot 2026-06-05 14:22，精度只到分钟，且部分老旧系统或容器环境可能缺失 utmp 条目，返回空 - 试图用
last reboot | tail -n +2拼凑“列表”不可靠：last不保证按时间严格倒序，且中间可能有缺失记录
没有 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中搜索kernel.*starting或INIT: version等关键词，可辅助定位无 reboot 记录的启动 - 注意
wtmp文件会被 logrotate 清理，默认保留 1~4 周，老记录永久丢失；没有备份机制的话，超过这个窗口就真查不到
journalctl --list-boots 给出的是前者，systemd-analyze time 的 Kernel start: 行才是后者——两者可能相差数秒，别混用。**
