linux下获取进程启动时间需读取/proc/[pid]/stat第22字段（jiffies），结合/proc/stat的btime和sysconf(_sc_clk_tck)换算为unix时间戳；windows则调用getprocesstimes()获取filetime后转换。
Linux 下读取 /proc/[pid]/stat 获取启动时间（jiffies）
Linux 内核把进程启动时间记录为相对于系统启动后的 clock_t 单位（即 jiffies），存在 /proc/[pid]/stat 的第 22 个字段。它不是绝对时间，需结合系统启动时间换算。
实操要点：
- 用
getpid()获取当前 pid，拼出路径如/proc/self/stat（推荐用self避免竞态） - 逐字段解析：用空格或制表符分割，跳过括号内的 comm 字段（第 2 字段是进程名，含空格，所以必须按括号配对逻辑跳过，不能简单 split 空格）
- 第 22 字段是
start_time，单位是sysconf(_SC_CLK_TCK)（通常为 100 Hz），不是秒 - 通过读取
/proc/stat中的btime行得到系统启动的 Unix 时间戳（秒级），再换算：process_start_sec = btime + start_time / (double)sysconf(_SC_CLK_TCK)
Windows 下调用 GetProcessTimes() 转为本地时间
Windows 提供 GetProcessTimes() 返回 FILETIME 类型的创建时间，这是 100 纳秒精度、自 1601-01-01 UTC 起的计数，需转成常用时间类型。
实操要点：
- 必须传入当前进程句柄：
GetCurrentProcess()，不能用OpenProcess()查自己（权限冗余且可能失败） -
FILETIME是低位/高位两个DWORD，需用FileTimeToSystemTime()或FileTimeToLocalFileTime() + FileTimeToSystemTime()转成本地可读时间 - 注意
GetProcessTimes()在 Windows 7+ 上可靠；旧系统（如 XP）某些服务进程可能返回 0 值，需校验lpCreationTime->dwLowDateTime != 0
跨平台封装要注意时钟源差异
Linux 的 btime 来自内核启动时间（/proc/sys/kernel/boot_time 已废弃），而 Windows 的 FILETIME 是绝对时间戳——两者语义不同，强行统一成 std::chrono::system_clock::time_point 时，Linux 侧必须依赖 /proc 可读，且无法在容器中精确反映“用户可见的启动时刻”（比如 systemd 容器可能延迟挂载 /proc）。
关键权衡点：
- 不建议封装成“一次调用返回
time_point”的函数，因为 Linux 侧有文件 I/O 和解析开销，Windows 是纯内存调用 - 若用于日志打点，Linux 下直接记
btime + start_time / CLOCKS_PER_SEC更轻量；Windows 下优先用GetSystemTimeAsFileTime()对比验证是否合理（防止虚拟机休眠导致时间跳变） - 容器环境（如 Docker）中，
/proc/[pid]/stat的start_time是容器启动后的时间，不是宿主机开机时间——这点常被忽略
常见错误：误把 timespec.tv_sec 当作进程启动时间
有人尝试用 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts) 或 CLOCK_MONOTONIC，但这返回的是 CPU 时间或单调时钟偏移，和进程生命周期无关。
典型误判现象：
- 子进程调用后值比父进程还小（因为
CLOCK_PROCESS_CPUTIME_ID是累计 CPU 时间，非 wall-clock） - 进程空闲时该值几乎不动，但实际已运行数小时
-
CLOCK_BOOTTIME是系统启动后单调递增，但它是全局的，不是 per-process 的
真正能表达“这个进程是什么时候被 exec 或 CreateProcess 启动的”，只有 Linux 的 /proc/[pid]/stat 第 22 字段，或 Windows 的 GetProcessTimes() 创建时间字段。其他时钟全都不对。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
