最直接有效的办法是用 uptime -s 或 who -b，两者都输出精确到秒的启动时间，且无需额外计算；uptime -s 输出 YYYY-MM-DD HH:MM:SS，who -b 输出 system boot YYYY-MM-DD HH:MM，后者兼容性更高。
最直接有效的办法是用 uptime -s 或 who -b，两者都输出精确到秒的启动时间，且无需额外计算。
uptime -s 直接显示系统启动时间戳
这个选项在绝大多数现代 Linux 发行版（包括 Ubuntu、CentOS、Debian）中都可用，输出格式为 YYYY-MM-DD HH:MM:SS，和系统时区一致。
-
uptime -s返回的是内核初始化完成、用户空间开始接管的时间，和systemctl status中的Since:字段基本一致 - 不依赖 systemd：哪怕系统用的是 sysvinit 或 openrc，只要 uptime 支持
-s，就能用 - 注意有些极简环境（如某些容器或嵌入式 busybox）可能不带该选项，会报错
invalid option -- 's'，此时应 fallback 到who -b - 脚本中建议加判断：
uptime -s 2>/dev/null || who -b | awk '{print $3, $4}'
who -b 是最兼容的启动时间来源
who -b 读取的是 /var/run/utmp 中由 init 进程写入的启动记录，不依赖任何服务管理器，兼容性比 uptime -s 更高。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 输出固定为
system boot YYYY-MM-DD HH:MM，没有秒级精度，但对日常运维完全够用 - 在 systemd 系统上，它和
uptime -s时间通常只差 1–2 秒；在非 systemd 系统上，这是唯一可靠的方式 - 如果执行后无输出，说明 utmp 文件损坏或被清空，可尝试
last reboot | head -1作为备选 - 注意：该命令普通用户即可运行，不需要 sudo
/proc/uptime + date 换算适合脚本化处理
当需要把启动时间嵌入监控脚本、生成日志前缀或做时间差计算时，手动换算是更可控的方式。
-
/proc/uptime第一列是浮点秒数（例如123456.78），代表系统自启动以来的总运行时间 - 用
date -d "@$(($(date +%s) - $(awk '{print int($1)}' /proc/uptime))"可得启动时间，但要注意：该命令在 shell 中需正确转义，推荐封装成函数 - 避免用
bc或awk做浮点减法再传给date，容易因精度丢失导致时间偏移 1 秒 - 如果系统时间被 NTP 调整过，
/proc/uptime不受影响，所以这个方法反而是最“真实”的内核视角启动时间
systemctl status 的 Since 行只适用于 systemd 系统
这个字段看着直观，但有明显限制：它反映的是 systemd 用户空间服务启动完成时刻，不是内核启动时刻。
- 输出类似
Since: Mon 2026-04-20 15:02:18 CST; 50min ago，其中时间是本地时区，ago是估算值，不建议用于精确计时 - 在容器或 minimal systemd 环境中，
systemctl status可能因权限或 dbus 未就绪而失败 - 不要用
systemctl show --property=UserspaceTimestamp，它返回的是纳秒级时间戳，需除以 1e9 才能给date -d @用，徒增出错概率 - 真正需要区分“内核启动”和“用户空间就绪”的场景极少，日常排查直接用
uptime -s就行
真正容易被忽略的是时区与精度混用问题：比如用 who -b 得到时间后，又拿它去和 journalctl 的 UTC 时间对比，结果发现差 8 小时。所有时间命令默认跟随系统本地时区，要统一分析，得先确认日志或监控系统是否强制用了 UTC。
