最可靠方式是优先用 uptime -s（输出 YYYY-MM-DD HH:MM:SS），失败则 fallback 到 who -b（兼容性最高），再失败用 last reboot | head -n 1 或 /proc/uptime 换算。
最可靠、最常用的方式是直接运行 uptime -s 或 who -b，两者都无需 sudo、不依赖 systemd、输出即用；若命令报错或无输出，说明环境受限，需 fallback 到 last reboot | head -n 1 或 /proc/uptime 换算。
uptime -s 输出启动时间戳（推荐首选）
该命令在绝大多数现代发行版（Ubuntu、CentOS、Debian、Arch 等）中可用，输出格式为 YYYY-MM-DD HH:MM:SS，和系统时区一致，精度到秒。
-
uptime -s返回的是内核初始化完成、用户空间开始接管的时间，与systemctl status中的Since:字段基本一致 - 不依赖 systemd：哪怕系统用的是 sysvinit 或 openrc，只要 uptime 支持
-s就能用 - 极简环境（如某些容器、busybox）可能报错
invalid option -- 's'，此时应立即换用who -b - 脚本中建议加容错：
uptime -s 2>/dev/null || who -b | awk '{print $3, $4}'
who -b 是兼容性最高的启动时间来源
who -b 读取的是 /var/run/utmp 中由 init 进程写入的原始启动记录，不经过任何服务管理器解析，因此兼容性远高于其他方式。
- 输出固定为
system boot YYYY-MM-DD HH:MM，无秒级精度，但对日常运维完全够用 - 在 systemd 系统上，它和
uptime -s时间通常只差 1–2 秒；在非 systemd 系统上，这是唯一稳定可用的方式 - 普通用户可直接运行，不需要 sudo
- 如果执行后无输出，说明
utmp文件损坏或被清空，此时应改用last reboot | head -1作为备选
/proc/uptime + date 换算适合脚本化处理
当需要把启动时间嵌入监控脚本、生成日志前缀或做时间差计算时，手动换算是更可控的方式。/proc/uptime 第一列是浮点秒数（例如 1234567.89），代表系统自启动以来的真实运行时间。
- 用
date -d "@$(($(date +%s) - $(awk '{print int($1)}' /proc/uptime))"可得启动时间，但 shell 中需注意转义，推荐封装成函数 - 避免用
bc或awk做浮点减法再传给date，容易因精度丢失导致时间偏移 1 秒 - 该方法不受 NTP 时间调整影响，反映的是内核视角的真实启动时刻，比
systemctl status更底层 - 在 WSL、某些嵌入式 Linux 或低权限容器中，
/proc/uptime可能返回Permission denied，此时必须 fallback
last reboot 和 journalctl --list-boots 用于历史回溯
这两个命令不适用于“当前启动时间”的快速查询，而是用来确认某次重启是否异常、比对多次启动间隔、或排查意外宕机。
-
last reboot | head -n 1显示最近一次 reboot 记录，格式为reboot system boot ...，时间字段来自/var/log/wtmp，可靠性高但依赖日志保留策略 -
journalctl --list-boots仅限 systemd 系统，输出带序号（0为当前），每行含精确到秒的起止时间，适合自动化解析 - 若
last reboot输出为空，可能是wtmp被清空或日志轮转策略过激；journalctl --list-boots在 journal 被禁用或/run/log/journal不可读时会失败 - 不要在 CI/CD 流水线里硬依赖这些命令的结果做超时判断——环境差异太大，且
wtmp和journal都可能缺失
真正关键的不是“用哪个命令”，而是理解每个命令背后的数据源：uptime -s 和 who -b 查的是 utmp，/proc/uptime 是内核计时器，journalctl --list-boots 读的是 systemd 日志索引。生产环境脚本里至少要准备两级 fallback，否则遇到容器、chroot 或 minimal init 环境就会卡住。
