Linux通过两次读取/proc/stat中cpu行的各状态时间片做差，计算活动时间占总时间比例得出CPU负载率；需间隔至少100ms，解析字段顺序为user、nice、system、idle、iowait等，空闲时间为idle+iowait。
Linux下用 /proc/stat 计算总CPU负载的原理和步骤
Linux没有现成的“系统级CPU负载百分比”API，/proc/stat 是最可靠、开销最小的来源。它记录了所有CPU核心自启动以来各状态（user、nice、system、idle、iowait等）的累计时间片（单位通常是USER_HZ，一般为100），通过两次采样做差值，再计算非空闲时间占比，就能得到近似负载率。
关键点：必须做两次读取并间隔一定时间（至少100ms），单次读取只能得累积值，无法反映瞬时负载。
- 每次读取后需解析第一行（以
cpu开头，注意末尾有空格），跳过后续每核单独的cpu0、cpu1等行 - 字段顺序固定：
user nice system idle iowait irq softirq steal guest guest_nice；其中idle和iowait都算空闲时间 - 总时间 =
user + nice + system + idle + iowait + irq + softirq + steal；活动时间 = 总时间 − (idle + iowait) - 两次采样间隔太短（如std::this_thread::sleep_for(200ms)控制
Windows下用 GetSystemTimes 获取总体CPU使用率
Windows提供GetSystemTimes函数，返回三个FILETIME：空闲时间、内核时间（含空闲）、用户时间。注意：内核时间包含空闲时间，所以不能直接用user + kernel当总时间——正确做法是用(kernel − idle) + user作活动时间，再除以两次采样的总时间差。
常见错误是把kernel当成纯忙时，导致结果偏高；另一个坑是FILETIME是100纳秒单位，需转为毫秒或微秒再做减法，否则整数溢出风险高。
立即学习“C++免费学习笔记（深入）”；
- 调用前检查函数是否可用（WinXP SP3+，且需
Advapi32.lib链接） - 第一次调用后等待100–500ms再第二次调用，避免时间差过小
- 差值计算务必用
ULARGE_INTEGER联合体转换，例如：ULARGE_INTEGER a; a.LowPart = ftIdle.LowPart; a.HighPart = ftIdle.HighPart; - 若
GetSystemTimes返回false（如在容器或某些精简版系统中被禁用），需降级到PDH库，但开销大、初始化复杂
C++跨平台封装时要注意的兼容性陷阱
别指望一个std::chrono::steady_clock加一套公式就能通吃。Linux和Windows对“空闲”的定义不一致（比如Windows的kernel含空闲，Linux的idle单独列出），直接套用同一套差分逻辑会出错。更麻烦的是macOS——它压根没公开的系统级总CPU统计接口，host_processor_info只返回每个核心的快照，且需要手动聚合，还受SIP限制。
- Linux：坚持用
/proc/stat，不要尝试sysconf(_SC_NPROCESSORS_ONLN)去归一化——负载率本身就不该除以核心数 - Windows：拒绝用
Performance Counter（如\Processor(_Total)\% Processor Time），它依赖WMI服务，启动慢、权限高、易被禁用 - macOS：若必须支持，用
host_processor_info+mach_host_self()，但要接受首次调用延迟高、且processor_cpu_load_info结构在不同版本中字段偏移可能变化 - 所有平台都要处理采样失败场景（文件不可读、API拒绝访问、时间倒流），返回
-1.0或抛异常比静默返回0更安全
为什么不用top或htop的输出来解析
因为它们不是系统接口，而是用户态工具，输出格式不稳定：top -bn1在不同终端宽度、不同版本下字段位置会变；htop甚至默认不输出总负载，得加--no-color --no-headers等一堆参数才能勉强稳定。更严重的是，fork+exec开销大，频繁调用会拖慢你的程序，还可能被安全策略拦截。
- 想快速验证逻辑？可以临时跑
cat /proc/stat | head -1看原始数据，但生产代码里绝不能popen("top -bn1") - 某些嵌入式Linux删掉了
/proc/stat（如部分Buildroot配置），此时应fallback到sysinfo结构体里的loads[0]（1分钟平均负载），但它不是百分比，是绝对值，且滞后严重 - 容器环境（Docker/K8s）中，
/proc/stat仍是宿主机全局视图，无法反映容器cgroup限制后的实际可用CPU——真要这个，得读/sys/fs/cgroup/cpuacct/...下的统计，那是另一套逻辑
