Linux下通过/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq读取实时主频（单位kHz，需÷1000转MHz），若不存在则fallback至cpuinfo_cur_freq；Windows通过WMI Win32_Processor.CurrentClockSpeed获取近似值（单位MHz），需初始化COM且受电源策略影响。
Linux下读取/sys/devices/system/cpu/cpu*/cpufreq/目录获取实时主频与调频状态
Linux内核通过sysfs暴露了每个逻辑CPU的当前频率、可用频率范围和调频策略，这是最轻量、无需特权且稳定的方式。注意：不是所有CPU都启用cpufreq子系统（如部分ARM板或禁用驱动时），需先确认路径存在。
- 检查是否存在
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq：若不存在，说明未加载cpufreq驱动（常见于虚拟机或精简内核） -
scaling_cur_freq单位为kHz，需除以1000转换为MHz；读取时可能返回0（尤其在空闲时），此时应 fallback 到cpuinfo_cur_freq（更可靠但更新略滞后） -
scaling_driver可判断当前使用何种调频器（如intel_pstate、acpi-cpufreq），不同驱动下scaling_cur_freq行为略有差异（intel_pstate默认不提供该文件，需启用no_hwp或改用energy_performance_preference接口） - 示例代码片段：
std::ifstream f("/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq");<br>long freq_khz = 0;<br>f >> freq_khz;<br>double freq_mhz = freq_khz / 1000.0;
Windows上用WMI查询Win32_Processor中的CurrentClockSpeed字段
Windows不直接暴露实时动态频率，CurrentClockSpeed是WMI提供的近似值，实际反映的是BIOS/ACPI报告的“当前工作频率”，受电源策略、Turbo Boost状态影响，每秒刷新一次左右，不能替代硬件寄存器级采样。
- 必须链接
comsuppw.lib并初始化COM（CoInitializeEx(nullptr, COINIT_MULTITHREADED)），否则WMI查询会失败 -
CurrentClockSpeed返回值单位为MHz，但某些旧版固件可能返回0或恒定值（如锁定在基础频率），此时建议同时读取MaxClockSpeed和Status字段辅助判断 - 避免高频轮询（如Win32_Processor实例在多核系统中每个逻辑处理器对应一条记录，需遍历
WHERE DeviceID LIKE 'CPU%'过滤 - 错误码常见
WBEM_E_INVALID_QUERY（语法错）、WBEM_E_NOT_FOUND（WMI服务未运行），应做兜底处理
跨平台方案慎用std::chrono或RDTSC测频——它不是主频
有人尝试用RDTSC指令配合时间戳差值反推CPU频率，这是典型误解：RDTSC返回的是自复位以来的周期数，现代CPU的TSC已非严格对应核心主频（存在恒定TSC、invariant TSC、频率缩放等机制），且无法区分P-state切换带来的瞬时变化。
-
RDTSC结果受cpuid序列化影响，未加屏障会导致乱序执行干扰计数，实测误差常达±15% -
std::chrono::steady_clock::now()底层依赖OS定时器（如Linux的CLOCK_MONOTONIC），与CPU频率无直接关系，不能用于反推 - 唯一可行的硬件级方法是读取MSR寄存器（如Intel的
IA32_APERF/IA32_MPERF），但需要管理员权限、驱动支持，且各厂商MSR定义不一，不具备通用性
macOS没有公开API获取实时核心频率，只能间接估算
Apple未向用户态开放CPU频率接口，sysctlbyname("hw.cpufrequency")返回的是标称最大频率（即MaxClockSpeed），host_processor_info()仅提供负载统计，无法反映瞬时P-state。
立即学习“C++免费学习笔记（深入）”；
- 第三方工具如
powermetrics（需sudo）可输出cpu_power节区中的frequency字段，但这是由I/O Kit驱动聚合上报的估算值，非每个核心独立采样 - 尝试读取
/usr/bin/ioreg -r -k "current-frequency"几乎总是空，因Apple在较新系统中移除了该属性 - 若应用对频率敏感（如音视频实时处理），应依赖
mach_timebase_info换算时间，而非试图获取“当前频率”——因为macOS的频率调度完全由系统透明管理，用户程序不应也不需感知
真正难的不是读哪个文件或调哪个API，而是理解“实时主频”本身在不同系统中语义不同：Linux暴露的是驱动层上报值，Windows是ACPI表快照，macOS干脆不暴露。调频状态（如是否处于boost、是否受限于thermal）更需结合温度、功耗、策略多维判断，单点读取意义有限。
