Windows需两次采样GetSystemTimes计算CPU使用率（非空闲时间占比），间隔≥100ms，FILETIME转毫秒再相减；内存使用率=(dwTotalPhys-dwAvailPhys)/(double)dwTotalPhys；GetProcessMemoryInfo需链接psapi.lib；Linux则解析/proc/stat和/proc/meminfo。
Windows 下用 GetSystemTimes 和 GetProcessMemoryInfo 算 CPU/内存使用率
Windows 没有直接返回“当前 CPU 使用率”的 API，得靠两次采样差值算；内存同理，GlobalMemoryStatusEx 只给总量和空闲量，使用率得自己除。
常见错误是只调一次 GetSystemTimes 就返回 0 或 100%，或者没处理好 100ns 单位的时间差转换。CPU 使用率本质是“非空闲时间占比”，必须至少间隔 100ms 以上采样才有点意义。
-
GetSystemTimes返回的三个FILETIME要转成 64 位毫秒再相减，别直接用ULARGE_INTEGER低 32 位 - 内存使用率 =
(dwTotalPhys - dwAvailPhys) / (double)dwTotalPhys，注意强制转double，否则整数除法结果永远是 0 - 需要
#include <psapi.h>并链接psapi.lib，否则GetProcessMemoryInfo链接失败
Linux 下读 /proc/stat 和 /proc/meminfo 最靠谱
Linux 没系统级 API 提供实时 CPU 使用率，标准做法就是解析 /proc/stat 的前几行（cpu、cpu0 等），取两次 jiffies 差值算比例；内存直接读 /proc/meminfo 里的 MemTotal: 和 MemAvailable:（不是 MemFree:）。
容易踩的坑是把 /proc/stat 所有字段当 long 读——第 1 行有 10+ 个字段，内核版本不同字段数可能变，必须按空格分割后跳过 cpu 前缀再转数字；另外 MemAvailable 在老内核（MemFree + Buffers + Cached - Shmem。
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream逐行读/proc/stat，遇到以"cpu "开头的行就解析，别硬写索引取第 2–5 字段 -
MemAvailable:字段末尾带kB，记得std::stoi前先substr(0, pos)截掉单位 - 频繁读
/proc文件开销极小，但别在循环里反复open/close，保持文件描述符复用更稳
C++ 跨平台封装要注意的三件事
真要写跨平台代码，别试图抽象出一个 get_cpu_usage() 接口然后内部 if-else——编译期分支比运行时判断更干净，也避免 Windows 下链接 Linux 函数或反过来报错。
最实际的做法是用宏分隔：#ifdef _WIN32 / #elif __linux__，各自实现，函数签名一致。别碰 POSIX 的 sysconf(_SC_NPROCESSORS_ONLN) 来算 CPU 核心数——它不等于逻辑核心数，也不反映当前负载。
- Windows 下
GetSystemTimes要求进程有SE_SYSTEM_PROFILE_NAME权限，普通用户默认有，但沙箱环境（如 VS Code 终端）可能被限制，此时返回FALSE且GetLastError() == ERROR_ACCESS_DENIED - Linux 下
/proc/meminfo的MemAvailable是估算值，和free命令输出一致，但比MemFree更真实反映可分配内存 - 别用
std::chrono::steady_clock对齐采样间隔——精度够，但两次采样间如果有线程切出、系统休眠，会导致 CPU 率虚高，加个usleep(100000)比较稳妥
为什么不用 std::thread::hardware_concurrency() 或 sysctl
std::thread::hardware_concurrency() 只返回逻辑核心数，和使用率无关；macOS 的 sysctl（如 vm.stats.vm.v_active_count）接口不稳定，10.15 后部分键被废弃，且不提供 CPU 时间片数据。
有人试过用 top -b -n1 或 ps 解析文本输出，这属于反模式：依赖 shell、易受 locale 影响、启动子进程开销大，还可能被安全策略拦截。
- macOS 真想拿 CPU 使用率，得用
host_processor_info+processor_info，但返回的是绝对 tick 数，仍需两次采样差值，和 Windows 逻辑一致 - 所有方案都绕不开“采样间隔”这个关键参数：太短（1s）响应滞后，100–500ms 是实用区间
- 没有“单次调用即得准确率”的方法，这是操作系统设计决定的——使用率本身就是统计概念，不是瞬时状态
事情说清了就结束。
