最轻量可靠的方法是直接读取/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq，该路径逐核返回实时频率（kHz），无需额外工具、不依赖用户态程序，且反映真实硬件状态。
直接读 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 最轻量可靠
这是唯一不需要额外安装、不依赖用户态工具、且能逐核显示实时频率的方法。每个 cpu* 目录下都有一个 scaling_cur_freq 文件，单位是 kHz，比如 2400000 就是 2.4 GHz。
- 执行
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq可一次性看到所有逻辑核当前值 - 用
watch -n 1 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq'每秒刷新，适合快速验证负载响应 - 若某核报错或输出为空，先检查该核是否 online：
cat /sys/devices/system/cpu/online；再确认路径是否存在：ls /sys/devices/system/cpu/cpu0/cpufreq/ - 数值长期不变？大概率是 governor 锁在
performance或powersave，查当前策略：cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cpupower frequency-info --freq 返回单核“主频”，不是全核快照
它读的是硬件寄存器，比 /proc/cpuinfo 的 cpu MHz 更准，但只返回一个数值——通常是调度器选中的“采样核”频率，不代表其他核状态。
- 必须加
sudo，否则报Permission denied - 若提示
No such file or directory，说明没加载频率驱动，运行dmesg | grep -i "cpu.*freq"看是否加载了intel_cpufreq或acpi-cpufreq - 输出类似
current frequency: 2.10 GHz (asserted by call to hardware)，括号里带asserted才算真实反馈 - 别用
watch -n 1 'cpupower frequency-info'，它默认不显示当前频率，容易误判
/proc/cpuinfo 的 cpu MHz 字段有缓存延迟
它由内核周期性更新，不是硬实时值。高负载突变后，可能滞后几百毫秒才刷新，不适合做性能归因分析。
- 执行
grep "cpu MHz" /proc/cpuinfo能看到全部逻辑核的值，但别只取第一行：grep "cpu MHz" /proc/cpuinfo | head -n 1会漏掉关键波动 - 数值是浮点格式（如
cpu MHz : 800.000），注意空格和冒号位置，提取时用awk '{print $4}'更稳 - 空闲时显示 800 MHz、满载时跳到 4200 MHz 是正常现象，反映的是睿频和节能策略联动，不是故障
需要每秒多核采样+时间戳？用 cpupower monitor
这是唯一能持续输出各核频率（kHz）、C-state、负载等组合数据的工具，适合压测或调优场景。
- 需
sudo，且内核必须启用CONFIG_X86_ACPI_CPUFREQ（Intel）或对应驱动（AMD/ARM） - 虚拟机里基本不可用，KVM/Xen 通常屏蔽底层寄存器访问
- 默认无时间戳，要对齐其他指标得自己加前缀：
sudo cpupower monitor | while read line; do echo "$(date +%s.%N) $line"; done - 输出每行包含
cpu0到cpuN的当前频率，字段对齐，适合awk或日志解析
scaling_cur_freq 文件路径是最值得优先检查的入口——它不绕路、不抽象、不依赖策略生效与否，只要 CPU 核在线且驱动就位，读出来就是此刻真值。其他方法要么单点、要么滞后、要么缺权限，别指望靠一个命令包打全场。 
