/proc/stat是Linux下解析每核CPU使用率的唯一可靠方式，内核每10ms更新一次；第一行cpu为全核汇总，后续cpu0、cpu1等对应各逻辑核；需两次采样取差值计算，总时间片为user+nice+system+idle+iowait+irq+softirq之和，其中idle和iowait视为空闲时间。
Linux下用/proc/stat解析每核CPU使用率
直接读/proc/stat是唯一可靠方式，内核每10ms更新一次，第一行cpu是全核汇总，后续cpu0、cpu1等对应各逻辑核。关键不是看绝对值，而是两次采样差值——user、nice、system、idle、iowait、irq、softirq这7个字段之和代表总时间片，其中idle和iowait算空闲，其余为忙时。别直接除以idle，会漏掉iowait。
实操建议：
- 至少间隔100ms采样两次，否则差值太小噪声大
- 用
std::ifstream逐行读/proc/stat，按空格分割后跳过首字段，再转uint64_t——stoull()比atoi()安全，避免溢出 - 注意：超线程的
cpu0和cpu1可能属同一物理核，需结合/sys/devices/system/cpu/cpu*/topology/core_id判断物理归属
获取每核当前频率要用/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
/sys接口返回的是kHz单位整数，比如2400000即2.4GHz。但得先确认该核启用了cpufreq驱动（cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver非空），否则文件不存在或返回0。很多云服务器默认禁用动态调频，此时所有核都显示标称频率或0。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 读
scaling_cur_freq返回-1或抛std::ios_base::failure异常——说明该核未启用cpufreq，改读cpuinfo_max_freq作近似 - 不同核返回频率差异极大（如一个3.2GHz一个800MHz）——大概率是intel的turbo boost或amd的boost active，属正常行为
- 频繁读取导致性能抖动——频率文件本质是内核sysfs接口，每次读触发一次ioctl，建议1秒最多读1次
上下文切换统计必须查/proc/[pid]/status里的ctxt字段
/proc/[pid]/status中ctxt行给出进程自启动以来的**总上下文切换次数**（voluntary + nonvoluntary），不是实时速率。要算每秒切换数，得自己存前值做减法。注意：这个值包含线程级切换，一个进程有10个线程，ctxt增长远快于单线程进程。
使用场景限制：
- 只对当前进程有效——
getpid()拿到pid后拼路径："/proc/" + std::to_string(getpid()) + "/status" - 无法区分自愿切换（如sleep、wait）和非自愿切换（如时间片耗尽）——
ctxt是两者之和，拆分需用perf_event_open或eBPF - 容器环境可能被cgroup限制——若
ctxt长时间不增长，检查是否被cpu.cfs_quota_us限频
Windows上没等价方案，只能妥协用GetSystemTimes
Windows没有 per-core 的精确CPU占用和频率API。GetSystemTimes()只返回全系统空闲/内核/用户时间，且精度低（15ms）、无每核分解。想接近Linux效果，得组合：QueryProcessCycleTime（进程周期数）、QueryThreadCycleTime（线程级）、Win32_PerfFormattedData_PerfOS_Processor WMI类（含% Processor Time，但仍是平均值）。
性能与兼容性影响：
- WMI查询慢（毫秒级），且远程调用可能超时；
QueryThreadCycleTime需遍历所有线程，开销随线程数线性增长 - 频率获取靠
CallNtPowerInformation(ProcessorInformation)，但仅部分版本支持，Win10 1809+才稳定返回当前频率 - 上下文切换数在
Win32_PerfRawData_PerfOS_Processor里有ContextSwitchesPerSec，但它是全系统统计，无法绑定到具体进程
真要跨平台做监控，别硬啃Windows原生API——用libpcap抓调度器事件或直接集成eBPF（Linux）/ETW（Windows）更靠谱，但开发成本高得多。多数情况下，接受Windows的数据粒度损失是现实选择。
