Linux下读取/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq获取当前实际运行频率（单位kHz），需遍历所有在线CPU并优先使用该文件，若不存在或返回0则fallback至cpuinfo_cur_freq或/proc/cpuinfo；注意intel_pstate等驱动可能禁用scaling_cur_freq，应结合scaling_driver判断机制。
Linux下读取/sys/devices/system/cpu/cpu*/cpufreq/目录获取基础频率信息
Linux内核通过sysfs暴露了每个CPU核心的频率相关数据，这是最轻量、无需root权限（多数字段只读）的方式。关键路径是/sys/devices/system/cpu/cpu0/cpufreq/，其中cpuinfo_cur_freq表示当前实际运行频率（单位kHz），scaling_cur_freq是cpufreq驱动上报的当前频率（可能缓存，更可靠），scaling_min_freq和scaling_max_freq对应当前策略下的频率范围。
注意：cpuinfo_cur_freq在某些内核或驱动下可能返回0或未实现，应优先尝试scaling_cur_freq；所有文件内容为ASCII文本，需用std::stoi或std::stoul转换，且要处理std::invalid_argument异常（比如文件为空或含非数字字符）。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 遍历
/sys/devices/system/cpu/下所有cpu[0-9]+子目录，避免硬编码核心数 - 对每个CPU读取
scaling_cur_freq，若失败则fallback到cpuinfo_cur_freq - 用
std::ifstream逐行读取，不依赖外部工具（如cat或lscpu） - 注意路径拼接时加
/，例如"/sys/devices/system/cpu/cpu" + std::to_string(i) + "/cpufreq/scaling_cur_freq"
Windows下调用WinRing0或QueryPerformanceCounter无法直接获取睿频状态
Windows没有公开API直接暴露CPU基础频率、睿频上限或当前是否处于睿频状态。WMI类Win32_Processor的MaxClockSpeed只是标称最大值（通常等于基础频率×倍频），不是实时睿频能力；CurrentClockSpeed字段在现代系统中基本失效，返回值常为0或过时。
立即学习“C++免费学习笔记（深入）”；
真正可行的路径只有两条：一是使用硬件厂商提供的SDK（如Intel的Intel PCM库，需管理员权限并加载驱动），二是读取MSR寄存器（Model Specific Register）。后者需要WinRing0或RDMSR驱动支持，且MSR_IA32_PERF_STATUS（0x198）等寄存器能提供当前倍频和电压，但解析复杂、平台差异大（不同微架构MSR位定义不同），且普通应用不应随意读MSR。
实操建议：
- 放弃
GetSystemInfo或WMI获取“实时睿频状态”的想法——它不存在于Windows标准API中 - 若必须做，用
Intel PCM（开源，C++接口清晰）替代自行读MSR，它已封装好getCoreFrequency()等函数 - 注意
Intel PCM初始化会尝试加载pcm-core.bin驱动，首次运行需管理员权限，后续可静默 - 不要尝试用
RDTSC测频率：它返回的是TSC周期数，受TSC频率恒定性（modern CPU usually invariant）、电源状态影响，不能反推核心频率
跨平台统一获取“当前有效频率”只能靠采样+估算，无法精确反映睿频瞬态
CPU频率在毫秒级动态变化，尤其在睿频场景下，一个核心可能在10ms内从800MHz跳到4.7GHz再回落。任何一次读取都只是快照，/sys或MSR返回的也是某一时刻的瞬时值，不代表持续能力。所谓“睿频状态”，本质是多个条件同时满足：温度低于阈值、功耗未超PL2、电流未达ITD、其他核心空闲——这些指标本身就不对外暴露。
因此，实用做法是：以100–500ms间隔连续读取scaling_cur_freq（Linux）或Intel PCM的getCoreFrequency()（Windows），统计最近N次的最大值、平均值、波动率。若最大值显著高于标称基础频率（如高出15%以上），可推测发生了睿频。
实操建议：
- 单次读取无意义，至少采集5–10个样本再判断趋势
- 避免在
sleep()中等待——用std::this_thread::sleep_for()配合高精度时钟（std::chrono::steady_clock）对齐采样点 - Linux下注意
scaling_driver类型：intel_pstate比acpi-cpufreq提供更细粒度数据，但前者默认禁用scaling_cur_freq，需启用no_hwp内核参数或改用intel_pstate的status接口 - 别把
max_freq当成睿频上限——它是当前策略允许的最大值，可能被用户用cpupower锁低
Intel Turbo Boost状态无法用代码“开启/关闭”，只能查询BIOS/OS策略是否允许
睿频（Turbo Boost）本身是硬件自动行为，软件无法直接触发或禁止。操作系统通过ACPI _PSS表或Intel p-state接口告知CPU可用的P-state列表，而Turbo Boost是否生效，取决于CPU内部逻辑对温度、功耗、电流的实时监测。代码能查到的，只有“当前是否在更高频率档位运行”，而非“Turbo Boost on/off”布尔值。
Linux下可通过/sys/devices/system/cpu/intel_pstate/status确认p-state驱动是否启用（active或passive），再看/sys/devices/system/cpu/intel_pstate/no_turbo：写入1可禁用Turbo Boost（需root），读取为0仅表示未手动禁用，不保证正在Turbo。
实操建议：
- 检查
/sys/devices/system/cpu/intel_pstate/no_turbo是唯一接近“Turbo开关状态”的指标，但它只是软件侧门控，不影响硬件是否具备能力 - 不要试图用
cpupower frequency-set --turbo on——该命令不存在，cpupower只能设P-state策略，不能控制Turbo逻辑 - 在虚拟机中读到的频率几乎总是固定值（如vCPU绑定到某物理核心后被hypervisor限制），此时所有频率接口均不可信
- ARM平台无Turbo Boost概念，类似机制叫
big.LITTLE调度或dvfs，需查/sys/devices/system/cpu/cpufreq/下不同cluster的独立路径
真正的难点不在读哪个文件或调哪个函数，而在于理解“频率”本身在现代CPU中就是一个模糊概念：它既不是恒定的，也不由单一变量控制，更不完全对软件透明。你拿到的永远是某个瞬间、某颗核心、某种测量方式下的近似值。
