c++标准库不提供跨平台的当前进程精确cpu时间片获取方式；clock()不可靠，std::chrono::steady_clock测的是墙上时间而非cpu时间；精确获取须依赖系统api：linux用clock_gettime(clock_process_cputime_id, ...)，windows用getthreadtimes()。
直接说结论：C++ 标准库不提供跨平台的“当前进程精确 CPU 时间片”获取方式；clock() 不可靠，std::chrono::steady_clock 测的是墙上时间，不是 CPU 时间——真要精确，得用操作系统 API。
Linux 下用 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) 拿线程级 CPU 时间
这是目前 Linux 上最精确、开销最小的方案，返回的是该进程（更准确说是调用线程）自启动以来在 CPU 上实际执行的时间，不含休眠、等待 I/O 的耗时。
注意点：
-
CLOCK_PROCESS_CPUTIME_ID是进程所有线程的 CPU 时间总和（POSIX 要求），但 glibc 实现中实际是调用线程的 CPU 时间——如果你用多线程且想统计整个进程，需在每个线程里分别采集再累加 - 返回值单位是纳秒，类型为
struct timespec，需手动转成浮点秒或微秒便于计算 - 必须链接
-lrt（部分旧系统需要，现代 glibc 通常默认可用）
#include <time.h>
#include <stdio.h><p>struct timespec ts;
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts) == 0) {
double cpu_ns = ts.tv_sec * 1e9 + ts.tv_nsec;
printf("CPU time: %.3f ms\n", cpu_ns / 1e6);
}</p></stdio.h></time.h>
Windows 下用 GetThreadTimes() 获取当前线程 CPU 时间
Windows 没有等价于 CLOCK_PROCESS_CPUTIME_ID 的全局进程 CPU 时间接口，GetThreadTimes() 只能查指定线程。要近似整个进程的 CPU 时间，一般取主线程（或你控制的 worker 线程）的 dwKernelTime + dwUserTime。
关键细节：
- 返回的
FILETIME是 100 纳秒为单位的 64 位整数，需转换：((ULONGLONG)ft.dwHighDateTime -
GetThreadTimes(GetCurrentThread(), ...)获取的是当前线程的 CPU 时间，不是整个进程——若进程含多个活跃线程，结果会显著偏低 - 该函数不计入内核驱动/中断上下文时间，但对用户态程序已足够精确
#include <windows.h>
#include <stdio.h><p>FILETIME ftCreate, ftExit, ftKernel, ftUser;
if (GetThreadTimes(GetCurrentThread(), &ftCreate, &ftExit, &ftKernel, &ftUser)) {
ULONGLONG kernel = ((ULONGLONG)ftKernel.dwHighDateTime </p>
<h3>别碰 <code>clock()</code>：它在不同平台语义混乱，且精度差</h3>
<p>很多老代码用 <code>clock()</code> 除以 <code>CLOCKS_PER_SEC</code> 算 CPU 时间，但问题极多：</p>
<ul>
<li>POSIX 规定它返回“处理器时间”，但 Linux glibc 实际返回的是墙上时间（<code>CLOCK_MONOTONIC</code> 类似行为），macOS 更是直接映射到 <code>mach_absolute_time()</code> —— 完全不是 CPU 时间</li>
<li>Windows 下它确实返回 CPU 时间，但仅限单线程，且精度常卡在 10–15ms（受系统 timer resolution 影响）</li>
<li>
<code>CLOCKS_PER_SEC</code> 在 POSIX 中固定为 1000000，但 Windows 是 1000，硬除会导致数量级错误</li>
</ul>
<p>一句话：只要目标是“CPU 时间”，就彻底放弃 <code>clock()</code>。</p>
<h3>性能计算公式实战：CPU 使用率 ≠ (delta_cpu_time / delta_wall_time)</h3>
<p>这个常见公式只在单线程、无阻塞、短周期采样下勉强可用。真实场景下极易误导：</p>
<ul>
<li>如果进程大部分时间在 <code>sleep()</code> 或 <code>read()</code> 等待，<code>delta_cpu_time</code> 接近 0，但分母 <code>delta_wall_time</code> 很大 → 算出“0% 使用率”，掩盖了它其实一唤醒就满载的事实</li>
<li>多线程下，<code>delta_cpu_time</code> 可能大于 <code>delta_wall_time</code>（比如 4 核上跑满 4 线程，1 秒墙钟内消耗 4 秒 CPU 时间），此时直接相除会得到 400%，需归一化为核数倍数</li>
<li>更稳健的做法是：用两次 <code>clock_gettime(CLOCK_PROCESS_CPUTIME_ID)</code> 差值 ÷ 两次 <code>clock_gettime(CLOCK_MONOTONIC)</code> 差值，再除以逻辑 CPU 数（<code>sysconf(_SC_NPROCESSORS_ONLN)</code>），得到平均核心占用率</li>
</ul>
<p>真正难的不是取数，而是理解“CPU 时间”在调度器视角下的含义：它是被内核会计子系统（如 cgroup v2 的 <code>cpu.stat</code>）记录的真实执行片段，任何绕过内核调度的测量（比如靠循环空转计时）都会失效。</p></stdio.h></windows.h>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
