最直接、最轻量、最可靠的方式是cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq，它不依赖额外工具、单位明确（kHz）、每核独立、内核原生实时输出；而/proc/cpuinfo的cpu MHz字段由内核缓存提供，存在滞后，无法反映毫秒级频率变化。
Linux下看CPU主频实时动态，cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 是最直接、最轻量、最可靠的方式——它不依赖额外工具，单位明确（kHz），每核独立，且是内核原生接口输出的真实值。
为什么不用 /proc/cpuinfo 的 cpu MHz？
/proc/cpuinfo 里的 cpu MHz 字段由内核缓存提供，不是硬件实时读取。常见现象是：你刚跑完 stress-ng，grep "cpu MHz" /proc/cpuinfo 还显示 800.000，而实际某核已升到 4.2 GHz；空载时也可能滞留在上一个高负载值上几秒。这不是 bug，而是设计使然——它本就不是为毫秒级监控准备的。
- 它只反映“某个采样时刻”的估算值，不保证与当前硬件状态同步
- 多核输出里，每个
cpu MHz行对应一个逻辑核，但head -n 1只取第一个，容易误判整体状态 - 虚拟机中该字段常被 hypervisor 固定为标称值，完全失真
scaling_cur_freq 怎么读才对？
路径 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 是 cpufreq 子系统暴露的实时频率文件，只要驱动加载（如 intel_cpufreq 或 acpi-cpufreq），无需 root 就可读（部分发行版默认允许普通用户读 sysfs）。
- 先确认存在：
ls /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq，若报错 No such file，说明 cpufreq 未启用（常见于 KVM 虚拟机、禁用变频的内核或某些 ARM 板） - 逐核读取：
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq，输出如2400000即 2.4 GHz；注意超线程逻辑核（如 cpu4、cpu5）可能和物理核频率不同 - 实时刷新：
watch -n 0.5 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq'，间隔设为 0.5 秒比 1 秒更能捕捉短时睿频脉冲 - 若某核输出为空，检查是否 offline：
cat /sys/devices/system/cpu/online，或被isolcpus隔离
为什么 cpupower frequency-info --freq 不适合动态观察？
它确实比 /proc/cpuinfo 更准——因为它绕过缓存，直读 sysfs 的 scaling_cur_freq，输出带 (asserted by call to hardware) 标识。但它本质仍是单次快照，不是流式接口。
- 执行一次就退出，无法持续跟踪波动；
watch -n 1 'cpupower frequency-info --freq'看起来像实时，实则每秒重建一次上下文，开销大且易丢帧 - 它默认只返回“策略级”频率（常取 cpu0 或调度主核），不代表所有核——大小核架构下，
cpu0（大核）和cpu8（小核）可能同时运行在完全不同频点 - 必须
sudo才能执行，而scaling_cur_freq文件多数情况下普通用户可读，权限更友好
容易被忽略的关键细节
真实场景里，频率动态不是单纯“升/降”，而是受多重机制叠加影响：调频策略（governor）、thermal throttling、RAPL 功耗限制、大小核调度、甚至 BIOS 中的 Turbo Boost 开关。只盯着一个数字，很容易归因错误。
- 对比
scaling_cur_freq和scaling_max_freq：前者接近后者 ≠ 睿频满血，还要看turbostat输出的 Turbo 列是否为 *，以及 pkg temperature 是否 >90°C - 大小核混布系统（如 Intel 12/13/14 代、ARM big.LITTLE）中，
cpu0-7和cpu8-15往往属于不同集群，频率档位和上限完全不同，必须分开看 - 容器或 cgroups v2 环境下，进程被限制在特定 CPUSet 时，其所在核的频率变化可能滞后于全局负载，需结合
cat /sys/fs/cgroup/cpuset/cpuset.cpus定位实际绑定核
