最可靠方法是读取/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq，该文件由cpufreq驱动实时维护瞬时频率（khz），比/proc/cpuinfo更准确；需普通权限，注意governor支持及路径遍历。
Linux下读取/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq最可靠
Linux内核通过cpufreq子系统暴露当前CPU频率，路径/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq（注意是scaling_cur_freq，不是cpuinfo_cur_freq）返回的是内核实际跟踪的、经采样更新的瞬时频率值，单位为kHz。该值由cpufreq驱动实时维护，比/proc/cpuinfo里静态的cpu MHz字段更贴近真实动态变化。
实操建议：
- 需以普通用户权限读取（多数发行版默认允许），无需root；若报
Permission denied，检查CONFIG_CPU_FREQ是否启用，或确认当前governor是否支持频率报告（如ondemand、performance通常支持，userspace可能不更新该值） - 每个逻辑CPU（包括超线程核心）有独立路径，遍历
/sys/devices/system/cpu/下所有cpu[0-9]+目录即可获取全部核心频率 - 该文件内容是纯数字文本，读取后需
std::stoll()转为整型再除以1000得到MHz值 - 不要轮询过快（如
Windows用QueryPerformanceCounter + RDTSC不可靠，应改用Win32_PerfFormattedData_Counters_ProcessorInformation
直接用RDTSC测周期再反推主频在现代CPU上完全失效：变频、Turbo Boost、多核共享环形总线、硬件P-state切换都会导致TSC与实际核心频率解耦。Windows原生不提供单核实时频率API，但WMI类Win32_PerfFormattedData_Counters_ProcessorInformation的PercentMaxFrequency字段可间接反映相对频率（需配合MaxClockSpeed计算）。
实操建议：
- 必须链接
wbemuuid.lib，初始化COM和WMI服务（CoInitializeEx、CoCreateInstance等步骤不可省） -
PercentMaxFrequency是百分比整数（0–100），对应当前核心最大睿频能力的占比；例如MaxClockSpeed=3500且PercentMaxFrequency=86，则约等于3010 MHz - 该值每秒更新1–2次，非严格实时，但比轮询注册表或PowerShell命令更轻量
- 注意：该WMI类在某些精简版Windows或禁用性能计数器的系统中可能返回空数据，需做
NULL指针和WBEM_E_NOT_FOUND错误处理
macOS没有公开API获取单核实时频率，sysctlbyname("hw.cpufrequency")只返回标称最大值
Apple明确不提供运行时核心频率接口，hw.cpufrequency和hw.cpufrequency_max都是编译时写死的标称值（如M1 Max标为3226 MHz），与实际运行频率无关。XNU内核虽在pmCPU中维护频率状态，但未导出到用户态。
实操建议：
- 可用
powermetrics --samplers smc | grep -i "freq"命令行临时抓取（需sudo），其底层调用SMC（System Management Controller）传感器，但该输出非稳定API，格式易变，不适合嵌入C++程序 - 试图通过
mach_timebase_info+ 高精度定时器推算频率，同样因ARM能效核/性能核异构、AVX指令停顿、内存延迟干扰而误差极大（±15%以上） - 若必须监控，唯一可行路径是解析
powermetrics的JSON输出（加-f json参数），但需依赖外部进程和权限，且macOS Ventura后部分字段被移除
C++跨平台封装要注意std::this_thread::sleep_for精度不足，优先用clock_gettime(CLOCK_MONOTONIC, ...)
获取频率本身只是第一步，真正难点在于以合适节奏采样并呈现“动态变化”。std::this_thread::sleep_for在Linux/macOS上底层依赖nanosleep，实际精度常为10–15ms；Windows上Sleep()最低仅15ms（受系统时钟节拍限制）。这会导致你读到的频率值看似“跳变”，实则是采样时机被系统调度拉平了。
实操建议：
- Linux/macOS下改用
clock_gettime(CLOCK_MONOTONIC, &ts)做高精度等待，结合忙等待（spin-wait）微调——例如先nanosleep到离目标时间100μs内，再用clock_gettime轮询 - 每次读取频率后，记录
clock_gettime时间戳，而非依赖固定间隔；后续绘图或统计时用真实Δt计算变化率 - 避免在循环中反复
open()/read()/close()同一scaling_cur_freq文件——缓存int fd并用pread重读，可减少系统调用开销 - 注意：即使做到微秒级采样，物理层面CPU频率本身也有几十微秒的响应延迟（P-state切换耗时），所谓“实时”本质是毫秒级可观测性
真正的瓶颈不在代码怎么写，而在你期望看到的“实时变化”是否真的存在——多数场景下，核心频率在几百毫秒内只发生几次阶跃式切换，中间平台期平坦如直线。盯着数字跳动不如看perf stat -e cycles,instructions,cache-misses -I 100更能理解负载与频率的实际关联。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
