GetProcessTimes 不能直接算出 CPU 使用率，因其仅返回进程内核态和用户态的累计时间（100 纳秒单位 FILETIME），需配合 GetSystemTimes（或 GetTickCount64 兼容方案）两次采样，计算进程时间差与系统可用 CPU 时间差的比值得到百分比，且多核下结果可能超 100%。
GetProcessTimes 为什么不能直接算出 CPU 使用率
GetProcessTimes 只返回进程的内核态和用户态时间（FILETIME），不是百分比，也不是实时采样值。它本身不包含“当前”这个概念——你得自己记录两次调用的时间差，再和系统总 CPU 时间做对比，才能推导出占用率。
常见错误是直接把 GetProcessTimes 返回的 dwUserTime / dwKernelTime 当成毫秒数去除以采样间隔，结果远超 100% 或完全不准。这是因为 FILETIME 是 100 纳秒为单位的 64 位整数，且必须转成毫秒再参与计算；更关键的是，单个进程时间不能脱离系统总时间看。
- 必须配合
GetSystemTimes（Windows Vista+）或自己估算系统总时间（XP 兼容路径） - 两次调用之间至少间隔 100–500ms，太短会导致精度崩坏（尤其低负载时）
- 多核下，进程时间可能超过采样间隔（比如 300ms 内跑了 800ms CPU 时间），所以最终要除以
核心数 × 采样间隔
Windows 10/11 下推荐做法：用 GetSystemTimes + GetProcessTimes
这是目前最准、最轻量的方式，不需要 WMI 或性能计数器那种重量级接口。
核心逻辑：取两次快照，分别拿到进程的累计 CPU 时间、系统总空闲/内核/用户时间，然后用差值算出该进程占系统总可用 CPU 时间的比例。
立即学习“C++免费学习笔记（深入）”；
-
GetSystemTimes的第三个参数（lpIdleTime）才是真正可被进程使用的“空闲窗口”，它和lpKernelTime、lpUserTime是互斥关系：系统总时间 = 内核 + 用户 + 空闲 - 系统总 CPU 可用时间 =
(kernel2 + user2) - (kernel1 + user1)，即非空闲时间之和 - 进程 CPU 时间 =
(proc_kernel2 + proc_user2) - (proc_kernel1 + proc_user1) - 最终百分比 =
(进程时间 / 系统可用时间) × 100.0，注意结果可能 >100%（多核并行）
示例关键片段（省略错误检查）：
FILETIME ftPrevSysIdle, ftPrevSysKernel, ftPrevSysUser;
FILETIME ftPrevProcKernel, ftPrevProcUser;
GetSystemTimes(&ftPrevSysIdle, &ftPrevSysKernel, &ftPrevSysUser);
GetProcessTimes(hProcess, nullptr, nullptr, &ftPrevProcKernel, &ftPrevProcUser);
<p>// ... sleep(500) ...</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill5502" title="C++ Code Review Master"><img
src="https://img.php.cn/upload/skill/000/000/081/179051228971575.jpg" alt="C++ Code Review Master" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill5502" title="C++ Code Review Master">C++ Code Review Master</a>
<p>组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。</p>
</div>
<a href="/xiazai/skill5502" title="C++ Code Review Master" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p>FILETIME ftCurSysIdle, ftCurSysKernel, ftCurSysUser;
FILETIME ftCurProcKernel, ftCurProcUser;
GetSystemTimes(&ftCurSysIdle, &ftCurSysKernel, &ftCurSysUser);
GetProcessTimes(hProcess, nullptr, nullptr, &ftCurProcKernel, &ftCurProcUser);</p><p>ULONGLONG prevSys = FileTimeToInt64(ftPrevSysKernel) + FileTimeToInt64(ftPrevSysUser);
ULONGLONG curSys = FileTimeToInt64(ftCurSysKernel) + FileTimeToInt64(ftCurSysUser);
ULONGLONG sysDelta = curSys - prevSys;</p><p>ULONGLONG prevProc = FileTimeToInt64(ftPrevProcKernel) + FileTimeToInt64(ftPrevProcUser);
ULONGLONG curProc = FileTimeToInt64(ftCurProcKernel) + FileTimeToInt64(ftCurProcUser);
ULONGLONG procDelta = curProc - prevProc;</p><p>double cpuPct = (double)procDelta / (double)sysDelta * 100.0;</p>Windows XP 兼容方案：用 GetTickCount64 估算系统总时间
XP 不支持 GetSystemTimes，但很多旧项目仍需兼容。这时只能退而求其次：用 GetTickCount64 获取两次采样之间的 wall-clock 时间，再乘以逻辑处理器数量，作为“系统最大可用 CPU 时间”的近似值。
这会高估实际 CPU 利用率（因为系统总有空闲），但在监控类场景中足够用于趋势判断。
- 必须用
GetTickCount64，而非GetTickCount（防 wrap-around） - 逻辑核心数用
GetSystemInfo().dwNumberOfProcessors获取 - 公式变成：
cpuPct = (procDelta / (tickDeltaMs × coreCount × 10000)) × 100.0（注意FILETIME是 100ns 单位） - 结果在低负载下容易偏低，在满载下反而接近真实值
容易被忽略的细节：FILETIME 转换和精度陷阱
FILETIME 是两个 DWORD 拼成的 64 位整数，直接强制转 ULONGLONG 在小端机器上没问题，但必须确保高位低位顺序正确。最安全写法是用 ULARGE_INTEGER union：
ULONGLONG FileTimeToInt64(const FILETIME& ft) {
ULARGE_INTEGER ul;
ul.LowPart = ft.dwLowDateTime;
ul.HighPart = ft.dwHighDateTime;
return ul.QuadPart;
}
另外，GetProcessTimes 对某些受保护进程（如 csrss.exe、winlogon.exe）会失败，返回 ERROR_ACCESS_DENIED，这不是代码问题，而是权限限制——别硬扛，跳过即可。
最后提醒一句：这个值本质是“过去 N 毫秒内的平均”，不是瞬时值；如果你看到 0%，不一定代表没运行，可能是采样期间刚好没调度到，或者时间太短没积累够 100ns 粒度。
