Linux下读/proc/uptime首个字段获精确运行秒数；Windows用GetTickCount64()有休眠偏差，高精度需WMI。
Linux 下直接读 /proc/uptime 是最轻量、最可靠的方式，不需要调用系统命令或依赖第三方库；Windows 则必须走 WMI 或 GetTickCount64()，但后者只表示开机后系统运行毫秒数，不等于“真实 uptime”（会受休眠影响）。
Linux：读取 /proc/uptime 获取精确开机时长
/proc/uptime 第一个字段是系统自启动以来的总空闲时间（单位：秒），第二个字段是总非空闲时间。我们真正需要的是第一个字段 —— 它代表系统已持续运行的秒数（内核级统计，精度高、无用户态干扰）。
实操建议：
- 用
std::ifstream打开/proc/uptime，读取首字段即可，无需解析第二字段 - 注意文件权限：普通用户可读，无需 root
- 不要用
system("uptime")或popen()解析输出 —— 多进程开销大，且输出格式可能随 locale 变化（比如中文系统里 “up 2 days” 变成 “up 2 天”） - 示例片段：
double uptime_sec = 0.0; std::ifstream f("/proc/uptime"); f >> uptime_sec;此时uptime_sec就是开机总秒数
Windows：用 GetTickCount64() 最简单，但有休眠偏差
GetTickCount64() 返回自系统启动以来的毫秒数，但它在系统进入睡眠/休眠状态时会暂停计数 —— 这意味着如果机器休眠过 3 小时，它报告的 uptime 会比真实开机时间少 3 小时。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 包含
<windows.h>，直接调用GetTickCount64()，返回值是ULONGLONG - 若需排除休眠影响，必须走 WMI 查询
Win32_OperatingSystem.LastBootUpTime，但初始化 COM、执行 WQL 查询开销大，且可能因权限或 WMI 服务异常失败 - 多数后台服务/监控场景接受
GetTickCount64()的休眠偏差，因其响应快、无依赖；关键审计场景才值得上 WMI - 别用
timeGetTime()—— 它是 32 位、有溢出风险（约 49.7 天），GetTickCount64()是唯一推荐的替代
记录运行日志：避免频繁写磁盘 + 时间戳对齐问题
日志不是“每秒写一次 uptime”，而是按需记录关键节点（如启动、异常退出、周期性快照），否则 I/O 压力大且日志膨胀快。
实操建议：
- 使用追加模式打开日志文件：
std::ofstream log("uptime.log", std::ios::app)，避免覆盖历史 - 时间戳统一用
std::chrono::system_clock::now()转本地时间，别依赖ctime()（受TZ环境变量影响） - Linux 下可把 uptime 秒数转为可读格式（如
days:hours:minutes:seconds）再写入，方便人眼识别；Windows 若用GetTickCount64()，建议同时记录当前系统时间，便于后续交叉验证休眠发生时段 - 务必检查
ofstream::is_open()和fail()，磁盘满、权限不足时静默失败比崩溃更危险
跨平台封装要点：别抽象过度，优先隔离条件编译
硬写一个 “UptimeProvider::get()” 接口看似整洁，但容易掩盖平台差异带来的语义鸿沟（比如 Windows 的休眠偏差是否要暴露给上层？）。
实操建议：
- 用
#ifdef _WIN32/#else/#endif直接分块实现，函数名保持一致（如get_system_uptime_seconds()），但注释明确写出各平台行为差异 - Linux 版本返回
static_cast<uint64_t>(uptime_sec)；Windows 版本返回GetTickCount64() / 1000（转秒），并在头文件注释里写清：“Windows 返回值不含休眠时长” - 不提供“自动补偿休眠”的通用函数 —— 补偿逻辑依赖具体业务对“uptime”的定义（是内核运行时间？还是用户期望的连续在线时间？），应由上层决定是否查 WMI 或结合事件日志
- 测试时务必在真实休眠唤醒后的 Windows 机器上验证数值跳变，这是最容易被忽略的验证点
真正难的不是读那个数字，而是想清楚你到底要度量什么：是内核连续运行时长？还是用户感知的“这台机器没关过机”？前者 Linux 几乎零误差，后者在 Windows 上永远得拼凑多源数据。
