最准、最省事的查法是uptime -s，它直接读取内核boottime变量，输出如2026-03-26 14:33:44，不依赖日志、不受NTP或手动调时影响，即使systemd崩溃或日志清空仍可靠，仅在极老系统（如CentOS 6）中不支持。
最准、最省事的方法就是 uptime -s，它直接读内核启动时间戳，输出形如 2026-03-26 14:33:44，不依赖日志、不被 NTP 校时干扰，脚本里用它最稳。
为什么 uptime -s 是首选
它从内核 boottime 变量直接取值，不是推算、不查文件、不走用户空间服务。哪怕 systemd 挂了、/var/log 被清空、journalctl 不可用，这个命令照样返回真实时间。注意：它反映的是“当时系统认为的启动时刻”，如果启动后手动大幅调过系统时间（比如 date -s），uptime -s 不会回溯修正——但这是正常行为，不是 bug。
- 输出格式固定为
YYYY-MM-DD HH:MM:SS，本地时区，无缩写 - 不支持该参数的老系统（如某些 CentOS 6 镜像）会报错：
uptime: invalid option -- 's'，这时要 fallback - 在监控脚本中优先用它，比拼接
/proc/uptime+date少两步、少出错
who -b 适合审计场景
who -b 读的是 /var/run/utmp，由 init 进程在进入多用户模式瞬间写入，是系统最早落盘的启动标记之一，安全审计常用。输出只有分钟级精度：system boot 2026-03-26 14:33。
- 它不显示秒，但足够定位到具体哪次重启
- 容器环境或异常关机可能导致
utmp清空，此时命令可能无输出或报cannot open /var/run/utmp - 若需转成带秒的时间戳，得靠组合：
date -d "$(who -b | awk '{print $3,$4}')" +'%Y-%m-%d %H:%M:%S'
last reboot 看历史，但别信第一条
last reboot 查 /var/log/wtmp，适合确认是否发生过意外重启。但它有个关键陷阱：最新一条记录末尾若标 still running，说明是当前会话；若标 (02:15) 或 crash，代表那次已结束。
-
last reboot | head -n 1不一定是最新的——部分发行版日志轮转逻辑会让新条目插在中间 - 更可靠的做法是：
last reboot | grep "still running" | head -n 1 -
wtmp可能被 logrotate 清理，低配 VPS 上常只保留最近几次记录
/proc/uptime 最底层，但要自己算
/proc/uptime 第一列是内核维护的浮点秒数（如 432189.12），绝对稳定，哪怕整个用户空间崩了也能读。但它不直接给时间，得用 date 反推：
date -d "@$(echo $(date +%s) - $(awk '{print int($1)}' /proc/uptime) | bc)"- 小数部分会被
int()截断，误差在 1 秒内 - 休眠（suspend）期间不计时，所以对笔记本用户，这个值可能小于真实开机天数
- 适合写自动化脚本，但日常查一次不如
uptime -s直观
真正容易被忽略的是时区和精度差异：uptime -s 和 who -b 都按本地时钟，但前者带秒、后者只到分；last reboot 的时间字段来自日志写入时刻，可能比内核启动晚几秒；而 /proc/uptime 换算结果依赖当前 date 命令的精度——如果系统刚同步过 NTP，反推时间可能和 uptime -s 差零点几秒。别纠结这几百毫秒，选对命令场景比追求“绝对精确”更重要。
