Linux下读取/sys/devices/system/cpu/cpu/cpufreq/scaling_cur_freq获取实时主频最直接可靠，但需注意空闲核返回0时应结合/proc/stat idle时间与cpu/online状态交叉验证，避免误判降频；Windows无可靠瞬时频率接口，macOS亦无等效方案。
Linux下读取/sys/devices/system/cpu/cpu*/cpufreq/目录获取实时主频
Linux内核通过sysfs暴露了每个逻辑CPU的当前频率、可用频率档位和调频策略，这是最直接、无需特权且稳定的方式。注意：不是所有CPU都启用cpufreq子系统（如某些嵌入式或虚拟机环境可能缺失），需先确认路径存在。
-
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq：当前实际运行频率（单位kHz），值为整数，可能因采样延迟略滞后于真实瞬时值 -
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq与scaling_min_freq：当前允许的动态上限/下限（kHz） -
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor：当前调频策略（如ondemand、performance、powersave） - 若读取
scaling_cur_freq返回0，常见原因是该CPU处于深度睡眠（C-state）未被调度唤醒，或驱动未上报——此时应 fallback 到cpuinfo_cur_freq（部分平台支持）或忽略该核
Windows上用QueryPerformanceCounter + RDTSC间接估算不可靠，改用WMI或PowerShell接口
Windows不提供标准API直接暴露每个核心的实时主频，RDTSC受频率缩放影响严重（尤其在Intel SpeedStep或AMD Cool'n'Quiet开启时），测出的是“参考周期数”而非真实Hz。可靠方式是调用WMI查询Win32_Processor类，但要注意它只返回标称最大频率（MaxClockSpeed）和当前负载相关估算值，非瞬时物理频率。
- 使用PowerShell命令：
Get-WmiObject Win32_Processor | Select-Object Name, MaxClockSpeed, CurrentClockSpeed—— 其中CurrentClockSpeed字段在部分Windows 10/11版本和硬件上才有效，多数情况下恒为0或MaxClockSpeed - C++中可通过
COM调用WMI，但需链接ole32.lib、oleaut32.lib，并处理大量样板代码；更轻量做法是用_popen执行PowerShell命令并解析输出 - 不要尝试用
__rdtsc()配合QueryPerformanceFrequency反推频率——现代CPU的TSC可能非恒定（invariant TSC需CPUID.80000007H:EDX[4]置位），且OS调度、中断、节能状态都会导致误差达±30%以上
跨平台封装建议：优先检测Linux sysfs，fallback到/proc/cpuinfo的cpu MHz字段
/proc/cpuinfo中的cpu MHz字段是内核在最近一次调度器tick时记录的近似值，精度低（通常刷新间隔20–100ms）、不反映单核瞬时变化，但胜在所有Linux发行版都存在、无需额外权限。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 对每个CPU核，读取
/proc/cpuinfo并按processor字段分组，提取对应cpu MHz行（例如cpu MHz : 2499.998） - 若目标程序需每秒多次采样，避免反复打开/关闭
/proc/cpuinfo——可一次性读入内存后正则匹配，或直接遍历/sys/devices/system/cpu/下的各核目录 - macOS无等效接口；其
sysctl hw.cpufrequency返回的是标称最大频率，powermetrics命令可输出实时频率但需root权限且输出格式不稳定，不适合嵌入C++程序
动态调频信息的关键判断点：仅依赖scaling_cur_freq无法区分“降频”还是“空闲”
Linux下scaling_cur_freq读数偏低时，必须结合/proc/stat中对应CPU的idle时间占比和/sys/devices/system/cpu/cpu*/online状态交叉验证——否则容易误判为调频故障。
立即学习“C++免费学习笔记（深入）”；
- 检查
/sys/devices/system/cpu/cpu0/online：值为0表示该核已被热拔出，此时任何频率读数均无效 - 读取
/proc/stat中cpu0行的第4列（idle时间，单位jiffies），与前一次采样对比，若idle占比持续>95%且scaling_cur_freq远低于scaling_min_freq，大概率是核心空闲而非调频异常 - 调频策略变更（如从
ondemand切到performance）会立即反映在scaling_max_freq和scaling_governor中，但scaling_cur_freq可能仍维持旧值直到下次负载触发调整
真正难的是把“读到一个数字”变成“理解此刻CPU到底在干什么”。频率只是表象，背后是调度器决策、ACPI P-state切换、微码干预和温度墙限制的混合结果——别指望单个文件给出全部答案。
