CLOCK_THREAD_CPUTIME_ID可获取当前线程用户态与内核态总CPU时间（纳秒级），但无法拆分二者；需分离时应读取/proc/self/task/[tid]/stat第14、15字段（utime/stime jiffies）并转换。
Linux 下用 clock_gettime 获取线程的用户态和内核态 CPU 时间
在 Linux 中，CLOCK_THREAD_CPUTIME_ID 是唯一能直接获取**当前线程**用户时间 + 内核时间总和的时钟 ID。它返回的是该线程自启动以来消耗的 CPU 时间（非挂钟时间），精度通常为纳秒级。
注意：clock_gettime 返回的是“总 CPU 时间”，无法拆分为用户态与内核态两部分——这是关键限制，很多开发者误以为它能分别读取二者。
- 必须链接
-lrt（glibc 的实时扩展库） - 调用前检查是否支持：
clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts)返回 0 才有效 - 若线程刚创建、尚未调度执行，可能返回 0 或极小值，不代表错误
真正分离用户/内核时间需读取 /proc/self/task/[tid]/stat
Linux 内核通过 /proc 文件系统暴露每个线程的详细调度统计，其中 /proc/self/task/[tid]/stat 的第 14 和 15 字段（从 1 开始计数）分别是该线程的 utime（用户态 jiffies）和 stime（内核态 jiffies）。
实操要点：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 先用
syscall(SYS_gettid)获取当前线程真实 TID（不是pthread_self()返回的 pthread_t） - 拼接路径：
/proc/self/task/+std::to_string(tid)+/stat - 逐字段解析：用空格分割后跳过前 13 个字段，取第 14（
utime）、第 15（stime）；注意字段可能含空格（如可执行名），但stat文件中第 2 字段是括号包裹的 comm，实际安全做法是用std::istringstream配合ignore跳过前 13 个 token - jiffies 需除以
sysconf(_SC_CLK_TCK)转为秒（典型值为 100），再乘以 1e9 得纳秒（如需对齐clock_gettime单位）
Windows 上用 GetThreadTimes 直接分离用户与内核时间
Windows 提供原生 API GetThreadTimes，可一次性获取创建时间、退出时间、内核时间、用户时间四个 FILETIME 值，且天然区分用户态与内核态。
使用注意事项：
- 传入当前线程句柄：
GetCurrentThread()，注意该句柄是伪句柄，无需关闭 -
FILETIME是 64 位整数，单位为 100 纳秒；转换为纳秒需乘以 100，转换为秒需除以 1e7 - 若线程已退出，
GetThreadTimes可能失败（返回 FALSE），需检查GetLastError() - 该 API 不可用在 UWP 应用中（受限于 AppContainer 沙箱）
跨平台封装要注意的三个坑
写通用工具函数时，最容易翻车的地方不是逻辑，而是细节一致性：
- Linux 下
/proc/[pid]/task/[tid]/stat中的utime/stime是累计值，但 Windows 的GetThreadTimes同样是累计值——二者语义一致，可直接对比，无需额外差分 - Linux 的 jiffies 值受
CONFIG_HZ编译选项影响，但sysconf(_SC_CLK_TCK)总是返回运行时真实值，务必用它而非硬编码 100 - macOS 不支持
CLOCK_THREAD_CPUTIME_ID，也没有等效的 per-thread/proc接口；若需支持 macOS，只能降级用CLOCK_PROCESS_CPUTIME_ID（整个进程）或依赖task_info+thread_info（需 mach 权限，且不保证用户/内核分离）
别指望一次封装覆盖所有平台还保持高精度——Linux 和 Windows 的机制本质不同，macOS 更是另起炉灶。按目标平台选方案比强求统一更可靠。
