uptime命令最直接查看系统运行时长，其输出中“up X days, Y:Z”字段表示连续运行时间，而非当前时间；加-p参数可提升可读性，-s参数返回启动时间戳。
uptime 命令直接看系统运行时长
Linux 下最直接、最轻量的方式就是 uptime。它不依赖额外工具，所有主流发行版都自带，输出里第一段数字就是系统连续运行了多久。
常见错误是只扫一眼就以为“12:34”是时间——其实那是当前时间；真正要看的是 up 5 days, 3:22 这类字段。如果显示 up 0 min，大概率刚重启过，或者系统被意外中断过（比如断电后自动恢复但内核重载）。
-
uptime默认只显示总时长和平均负载，加-p参数可读性更强（如up 5 days, 3 hours, 22 minutes） - 加
-s可查启动时间戳：uptime -s输出类似2024-03-15 08:22:11，适合脚本取值 - 注意：容器环境里
uptime显示的是容器启动时间，不是宿主机——别在 Docker 里跑完就误判宿主机 uptime
/proc/uptime 文件提供高精度原始数据
/proc/uptime 是内核暴露的只读文件，内容是两个空格分隔的浮点数：123456.78 98765.43。前者是系统开机至今的秒数（含小数），后者是系统处于空闲状态的秒数。
它比 uptime 更底层、更精确，适合写监控脚本或需要毫秒级对齐的场景。但直接读出来是秒，得自己换算成天/小时/分钟。
- 用
awk '{print int($1/86400) " days, " int($1%86400/3600) " hours"}' /proc/uptime快速粗算 - 脚本中建议用
bc或printf处理小数部分，避免 shell 整数截断出错 - 该文件在 WSL、某些嵌入式 Linux 或低权限容器中可能不可读（
Permission denied），此时 fallback 到uptime -s更稳妥
systemctl show --property=UserspaceTimestamp 拿不到开机时间
有人试过 systemctl show --property=UserspaceTimestamp，发现返回空或报错，是因为这个属性只在 systemd 启动后才记录，且依赖 systemd-tmpfiles-setup 等早期服务正常运行。一旦启动流程卡在 initramfs 阶段（比如磁盘检测慢），它就不可靠。
更关键的是：它反映的是 userspace 初始化完成的时间，不是内核启动时刻。两者可能差几秒到几十秒——对日志溯源或故障定界来说，这个偏差不能忽略。
- 真正想查内核启动时间，优先用
dmesg -T | head -1（带时间戳的第一条内核日志） - 若
dmesg时间不准（比如没配置 NTP 或日志缓冲区被刷掉），/proc/sys/kernel/osrelease配合uptime -s是更稳的组合 - 不要在 CI/CD 流水线里硬依赖
systemctl show的时间字段做超时判断——环境差异太大
Python 脚本里别用 time.time() - boot_time
有人写 Python 监控脚本，想用 time.time() - boot_time 计算运行时长，结果发现值偏小甚至为负。问题出在：Python 的 time.time() 返回的是 wall clock 时间，受系统时钟调整（NTP、手动改时间）影响；而 boot time 是固定瞬间，两者不在同一时间轴上对齐。
正确做法是读 /proc/uptime，再用 time.time() 减去当前 uptime，倒推出启动时间——这样即使系统时间被调过，结果依然准确。
- 示例：用
with open('/proc/uptime') as f: uptime_sec = float(f.readline().split()[0]) - 然后
boot_time = time.time() - uptime_sec，这才是可靠的启动时间戳 - 注意 Python 进程启动晚于系统启动，所以这个
boot_time是估算值，误差在毫秒级，够用但别当纳秒级精度用
真正麻烦的是虚拟机或云主机——hypervisor 可能暂停过 guest，/proc/uptime 却不会跳变。这时候“运行时间”本身语义就模糊了：你到底要物理连续运行时长，还是 guest 感知到的 CPU 时间？得先想清楚这个问题，再选工具。
