直接读/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq是最轻量、每核独立、单位明确（kHz）、毫秒级响应的实时频率监控方式，绕过缓存直读硬件，输出如2400000即2.4GHz；需sudo权限，路径缺失则说明cpufreq驱动未加载或核心offline。
直接读 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 最轻量实时
这是唯一不依赖额外工具、每核独立、单位明确（kHz）、毫秒级响应的方式。路径里的 cpu* 会匹配所有逻辑核心，比如 cpu0 到 cpu15，每个文件内容就是该核当前真实频率值。
常见错误是只看 cpu0：单条命令 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 容易误判多核负载不均场景；正确做法是批量读取：cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq，或加 watch -n 0.5 实时刷屏观察波动。
- 输出为纯数字，如
2400000表示 2.4 GHz，800000表示 0.8 GHz - 若某核报
No such file or directory，先检查该核是否 offline：cat /sys/devices/system/cpu/online；或被isolcpus隔离 - 路径不存在（
/sys/devices/system/cpu/cpu0/cpufreq/）说明没加载 cpufreq 驱动，查dmesg | grep -i "cpu.*freq"确认intel_cpufreq或acpi-cpufreq是否已启用
cpupower frequency-info --freq 是最准的“此刻”单值
它绕过内核缓存，直接从 sysfs 接口读取硬件寄存器反馈，比 /proc/cpuinfo 的 cpu MHz 字段更及时——尤其在频率快速切换（如短突发负载后降频）时，后者可能滞后几百毫秒。
但注意：它只返回一个数值，不代表全部核心；默认是“调度主核”或采样核的频率，不是最大/最小值。
- 必须加
sudo，否则报Permission denied - 输出格式类似
current frequency: 3.60 GHz (asserted by call to hardware)，括号里带asserted才算真正硬件反馈 - 如果提示
No such file or directory，不是命令错，而是底层驱动未就绪，和上面 sysfs 路径缺失是同一原因
用 turbostat 看睿频是否真超基频
只有 turbostat 能告诉你某个核心当前频率是否真的超过了 CPU 规格里的基础频率（base frequency），也就是常说的“睿频生效”。它显示的是原始 GHz 值 + Turbo 标志列，不是估算值。
例如：CPU 基频 2.8 GHz，cpuinfo_max_freq 是 4700000（4.7 GHz），但 turbostat 中某核显示 Core MHz 为 4900 且 Turbo 列为 ✓，才说明实际触发了超频。
- 必须
sudo运行，否则 MSR 寄存器读取失败，关键字段为空 - 仅对 Intel CPU 有完整意义；AMD 平台部分字段无定义，虚拟机中基本不可用（KVM/Xen 屏蔽 MSR）
- 输出默认无时间戳，需配合
--interval 1控制刷新，并用stdbuf -oL避免管道缓冲延迟
别把 lscpu 的 CPU MHz 当实时值用
lscpu | grep "CPU MHz" 显示的是内核估算的平均频率，不是任一核心的瞬时值。空载时它可能还停在 2.4 GHz，而实际所有核都已降到 800 MHz —— 这个字段只适合做 baseline 参考，比如对比 performance 和 powersave 模式下的整体趋势。
真正有用的静态边界值是：CPU max MHz（硬件支持的最高睿频上限）和 CPU min MHz（节能下可压到的最低值）。但要注意：多插槽系统中，不同物理 CPU 的 max MHz 可能不同，而 lscpu 只报告第一个 socket 的值。
- 如果
CPU max MHz显示unknown，说明内核版本太旧或驱动未加载，此时得靠cpupower frequency-info查hardware limits段 -
model name里的频率（如@ 3.70GHz）是标称基础频率，不含睿频，不能和scaling_cur_freq直接比较来判断是否睿频
scaling_cur_freq 文件路径是否可用、turbostat 能否读 MSR、甚至 BIOS 是否开了 Turbo Boost，三者缺一都会让“查看动态主频”这件事失效——不是命令输错了，而是底层链路断了。 
