实时cpu利用率必须通过两次采样差值计算，分母必须为真实流逝时间（如windows用gettickcount64、linux用clock_monotonic），否则结果失真；单进程监控windows推荐getprocesstimes+gettickcount64，linux推荐解析/proc/self/stat与/proc/stat，避免pdh、top、ps等封装层。
不能直接调用一个函数就拿到“实时CPU利用率百分比”——所有可靠实现都依赖两次采样差值，且必须用真实流逝时间（wall-clock time）作分母，否则结果在多核、空闲或调度不均时完全失真。
Windows下用GetProcessTimes + GetTickCount64算单进程占比
这是最轻量、无需额外权限、兼容Win7+的方式。关键不是读时间，而是怎么归一化：
-
GetProcessTimes返回的FILETIME是100纳秒单位，必须转成毫秒再相减：用ULARGE_INTEGER联合体取低64位，除以10000得毫秒 - 分母不能用
std::chrono::steady_clock或clock()，它们测的是进程挂起时间；必须用GetTickCount64()——它返回系统启动后毫秒数，且不受睡眠/挂起影响 - 两次采样间隔建议 ≥ 200ms：太短会导致
delta CPU time为0，或因计时器分辨率不足而抖动剧烈 - 结果可能 >100%：比如双核上满载运行，300ms内用了580ms CPU时间，算出来就是≈193%，这属于正常现象，反映的是“总CPU时间占比”，不是单核限制
Linux下解析/proc/self/stat和/proc/stat
没有API封装，靠文件读取+手动计算，但最准、无额外进程开销：
-
/proc/self/stat第14字段（utime）和第15字段（stime）是用户态与内核态jiffies，相加即总CPU时间；注意字段索引从0开始，且命令名含空格需跳过括号部分 -
/proc/stat第一行以cpu开头的行，前四个数字（user+nice+system+idle）之和是系统总jiffies；别硬编码HZ=100，用sysconf(_SC_CLK_TCK)动态获取 - 两次采样间的真实时间差必须用
clock_gettime(CLOCK_MONOTONIC, &ts)，不能用gettimeofday（NTP调整会干扰） - 刚启动的进程
utime/stime可能为0，首次差值易偏高，建议丢弃第一次结果
为什么PDH或top -b -n1不适合嵌入式监控
它们不是底层接口，而是封装层，带来延迟、权限和语义歧义：
-
PdhAddCounter要求传入进程名字符串，多实例时无法区分PID，容易绑错目标；且首次PdhCollectQueryData后必须等待≥100ms，否则第二次采集永远返回0 -
top -b -n1 | grep依赖shell环境、输出格式稳定性（不同版本top字段顺序可能变），且启动子进程本身就会污染被测进程的CPU时间 -
ps的%cpu字段是生命周期平均值，完全不能反映瞬时负载，比如一个跑5分钟只占1%的进程，刚启动那1秒满载，ps仍显示≈1% - 所有基于性能计数器的方案都需要
SeDebugPrivilege或管理员权限才能查其他进程，而GetProcessTimes对自身进程只需默认句柄
跨平台采样节奏控制别用std::this_thread::sleep_for
系统调度精度远低于你预期的毫秒级，尤其在负载高时：
- Linux默认timer resolution约10–15ms，Windows可能更差；
sleep_for(200ms)实际可能停230ms甚至310ms，导致分母不准，最终CPU%跳变或超限 - 正确做法是用
std::chrono::steady_clock::now()记起点，每次循环检查是否达到目标间隔，未到则sleep_for(1ms)再试——主动轮询比被动等待更可控 - 别把两次
utime+stime直接相减当“本次CPU时间”：如果进程在采样间隙被抢占或休眠，这部分时间仍计入分母，但不计入分子，结果自然偏低，这是设计使然，不是bug
真正难的不是读数据，而是理解「CPU占用率」本质是采样窗口内的相对比例——窗口太小没意义，太大失实时性；分子是进程真实执行时间，分母必须是同一窗口内系统总可用CPU时间，缺一不可。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
