uptime是最轻量准确的判断linux系统是否重启过的方式，它直接读取/proc/uptime，输出连续运行时长，不包含休眠时间，且在容器中显示宿主机运行时间而非容器本身。
uptime 命令直接看系统运行了多久
Linux 系统开机后没重启过？uptime 是最轻量、最准的判断方式。它不查日志、不读内核模块，只从 /proc/uptime 里拿原始数据，毫秒级准确。
直接运行：
uptime输出类似
14:22:05 up 12 days, 3:47, 2 users, load average: 0.12, 0.08, 0.05 —— 关键就是 up 12 days, 3:47 这段。-
up后面的时间是「连续运行时长」，不是“上次启动时间”，也不包含休眠或挂起时间 - 如果看到
up 0 min或up 1 min，基本说明刚重启过，或者系统被硬重启过（比如断电） - 注意空格和逗号：不同发行版输出格式略有差异，但
up关键字和后续时间字段始终存在
想精确到秒？加 -p 参数
默认输出是“天+小时+分钟”组合，人眼友好但不利于脚本解析。uptime -p 统一用英文短语表达，更稳定：
uptime -p
输出如：up 12 days, 3 hours, 47 minutes。比默认多出“hours”“minutes”字样，避免歧义（比如 3:47 容易被误读为时间点）。
- 这个参数在较新 systemd 系统（如 Ubuntu 16.04+、CentOS 8+）才支持；老系统会报错
uptime: invalid option -- 'p' - 脚本中要用它，得先判断：
uptime --version 2>/dev/null | grep -q "procps-ng" && uptime -p || uptime
- 别用
uptime -s替代——它返回的是启动时间戳（如2024-03-15 10:35:22），要算时长还得自己做时间差
为什么 uptime 比 last reboot 更可靠
last reboot 查的是 /var/log/wtmp 记录，而这个文件可能被轮转、清空、权限限制，甚至某些容器环境压根没开 wtmp。
-
uptime读/proc/uptime，只要内核活着就一定有值，连 root 权限都不需要 - 遇到
last reboot输出为空或只有几条记录？先跑uptime确认系统是否真重启过 - 虚拟机迁移、kdump 崩溃恢复后，
last可能漏掉一次 reboot，但uptime的计数会归零重来，信号更干净
注意：容器里 uptime 显示的是宿主机时间
在 Docker 或 Podman 容器中执行 uptime，看到的不是容器启动时长，而是宿主机的运行时间。这是由 Linux cgroup 和 /proc 文件系统共享机制决定的，无法绕过。
- 想查容器本身存活多久？得看
docker inspect <container> | grep StartedAt</container>或podman inspect <container> | grep -i started</container> - 误把容器里的
uptime当作服务运行时间，是运维排查中最常见的定位偏差之一 - systemd 服务里用
ExecStartPre=/usr/bin/uptime打日志？小心日志里全是宿主机数据，跟服务生命周期对不上
系统运行时间这事，表面看只是个数字，但背后连着启动可靠性、故障窗口判断、甚至合规审计。真正容易被忽略的，是容器场景下的语义混淆——同一行命令，在不同上下文里代表完全不同的东西。
