Windows下QueryPerformanceFrequency返回的是性能计数器频率而非CPU频率；真正反映当前CPU频率需用WMI的Win32_Processor.CurrentClockSpeed（单位MHz，代表所有核心最高报告频率），或底层读取MSR寄存器（需管理员权限）。
Windows下用QueryPerformanceFrequency只能得到计时器频率，不是CPU频率
很多人误以为QueryPerformanceFrequency返回的是CPU主频，其实它返回的是高精度性能计数器（HPET或TSC）的基准频率，和CPU当前运行频率无关。这个值通常是固定常量（比如3.4 MHz或10 MHz），跟CPU睿频、降频、P-state切换完全不挂钩。
真正反映“当前CPU频率”的数据，Windows本身并不直接暴露给用户态程序——它由ACPI驱动和处理器电源管理（PPM）动态控制，且不同核心可能处于不同频率档位。
推荐方案：读取Win32_Processor WMI类的CurrentClockSpeed属性
这是最接近“当前CPU频率”的公开接口，虽然它并非实时采样（实际是最近一次P-state切换后报告的值），但对大多数监控/诊断场景已足够可靠。
- 需要链接
ole32.lib和oleaut32.lib - 必须调用
CoInitializeEx(nullptr, COINIT_MULTITHREADED)初始化COM -
CurrentClockSpeed单位是MHz，注意它是uint32类型，可能被截断（如实际3.8 GHz会显示为3800） - 多核系统下该值代表“所有核心当前报告的最高频率”，不是每个核心的独立值
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
IEnumWbemClassObject* pEnumerator = nullptr;
hres = pSvc->ExecQuery(bstr_t("WQL"), bstr_t("SELECT CurrentClockSpeed FROM Win32_Processor"),
WBEM_FLAG_FORWARD_ONLY | WBEM_FLAG_RETURN_IMMEDIATELY, nullptr, &pEnumerator);
// 后续用Next()取结果，再用GetNames()/GetValue()提取CurrentClockSpeed字段
更底层但受限：读取MSR寄存器中的IA32_APERF/IA32_MPERF
Intel CPU支持通过__readmsr(0xE8)（IA32_APERF）和__readmsr(0xE7)（IA32_MPERF）计算一段时间内的平均频率，公式为：(APERF2 - APERF1) / (MPERF2 - MPERF1) * 基准频率。其中基准频率通常取MaxClockSpeed（来自WMI）或CPUID 0x16返回的标称频率。
- 需要管理员权限 + 驱动级支持（用户态直接
__readmsr会触发#GP异常） - Windows默认禁用用户态MSR访问；若强行用驱动（如WinRing0）绕过，稳定性与兼容性风险陡增
- AMD平台对应MSR不同（
0xC0010068等），且文档支持弱 - 两次采样间隔太短会导致精度崩坏，建议≥100ms
别踩坑：不要用RDTSC除以时间算频率
RDTSC读取的是TSC计数器，现代CPU中TSC通常是恒定速率（Invariant TSC），与当前核心频率无关。即使TSC非恒定（已基本淘汰），其变化也受多种微架构因素干扰，无法反推出真实运行频率。
常见错误写法：
auto t0 = __rdtsc(); Sleep(1000); auto t1 = __rdtsc(); double freq = (t1 - t0) / 1.0e6; // 错！这不是GHz，只是TSC增量/毫秒
这种结果可能在不同CPU型号、不同电源计划下剧烈波动，且无法区分睿频/基础频/加速状态。
真正想做精细频率追踪，得结合ETW事件（Microsoft-Windows-Kernel-Processor-Power提供P-state切换日志）或使用PowerShell Get-CimInstance Win32_Processor定期轮询——但注意，WMI本身也有缓存延迟，两次查询间隔不宜低于500ms。
