要查看 Linux 系统中 CPU 各逻辑核心的实时主频，最可靠的方法是直接读取 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 文件。该文件以 kHz 为单位记录频率，无需 root 权限即可访问。操作时需遍历每个逻辑核，并确保 cpufreq 驱动已启用，尤其在虚拟机或大小核异构架构中，避免出现误判。
最可靠方式：直接读取 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 获取 CPU 实时主频
每个逻辑核心的实时主频都以明文形式存储在该文件中，单位为 kHz，例如 2400000 表示 2.4 GHz。该值由内核的 cpufreq 子系统动态更新，相比 /proc/cpuinfo 中的 cpu MHz 字段更加及时——后者存在毫秒级的缓存延迟。而且无需 root 权限，只要文件具有可读权限即可。
实际操作时，几个要点值得注意：
- 首先确认路径是否存在：执行
ls /sys/devices/system/cpu/cpu0/cpufreq/，如果出现错误或目录为空，则表示 cpufreq 驱动未启用（常见于虚拟机、部分 ARM 开发板，或 BIOS 中已关闭 SpeedStep 功能）。 - 逐核进行读取：使用命令
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq，其中cpu*通配符将匹配所有在线的逻辑核心（包括超线程）。切勿仅查看cpu0就认为已经获取了全部核心的频率信息。 - 如果返回值为空或提示
No such file or directory，则可能该核心已被isolcpus参数隔离，或当前处于离线状态。可通过执行cat /sys/devices/system/cpu/online来确认在线核心的情况。
使用 watch -n 1 实时监测频率波动，而非 cpupower frequency-info
cpupower frequency-info --freq 虽然能提供一定准确度，但它只会返回单一数值——通常是“采样核心”的频率，无法体现多核异步调频的实际行为。相比之下，watch -n 1 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq' 命令每秒刷新一次所有核心的频率值，可以直观地观察到哪些核心正在升频、哪些保持在低频，以及是否存在大小核之间的梯度差异。
几个容易踩的坑：
- 注意不要误写为
watch -n 1 'cpupower frequency-info'——该命令默认不会输出当前频率，仅刷新 policy 概览，容易导致误判。 - 输出的结果不包含时间戳，如果需要与其他监控指标（如负载、温度）对齐，可以手动添加时间前缀：
watch -n 1 'date +"%T"; cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq'。 - 过高的刷新频率（例如
-n 0.1）反而会引起 I/O 抖动，导致数值失真——1 秒的刷新间隔已经足够捕捉典型的负载跳变情况。
在大小核架构中必须区分 P-core 与 E-core 的频率
在 Intel 第12代及以上、AMD Ryzen 7040系列及以上的大小核 CPU 中，P-core（性能核）与 E-core（能效核）具有截然不同的频率范围和响应策略。任务管理器或简单的 lscpu 输出往往会掩盖这种差异，容易造成“频率没有变化”的误判。
正确的做法应该是：
- 首先按物理拓扑定位核心：执行
lscpu | grep "CPU(s):"确认总的逻辑核心数量，然后使用cat /sys/devices/system/cpu/cpu*/topology/core_type查看核心类型——值为 0 表示 P-core，值为 1 表示 E-core。 - 分别进行监控：例如使用命令
watch -n 1 'for i in $(seq 0 7); do echo -n "cpu$i: "; cat /sys/devices/system/cpu/cpu$i/cpufreq/scaling_cur_freq 2>/dev/null; done'，然后人工比对 P-core 与 E-core 的数值区间来区分差异。 - 如果所有核心的频率同步变化且没有梯度差异，很可能是 Windows 电源计划设置为“高性能”并禁用了 Core Parking，或是 Linux 内核未能正确识别 CPU 拓扑。此时可以检查
dmesg | grep -i "hybrid"的输出，以定位问题。
出现频率波动异常时，优先检查 scaling_governor 和 scaling_max_freq
频率没有变化并不等于硬件出现故障，更可能是 CPU 策略被锁定或频率上限被压低。需要从以下三个方面联动验证：
- 检查调速器：运行
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor，如果显示performance但频率没有变化，说明硬件已触达温度或功耗上限；如果显示ondemand却长期静止，则可能是负载未达到升频阈值——通常需要持续超过 95% 几秒钟才会触发频率提升。 - 对比频率上下限：执行
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq和cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq，如果两者数值相等（例如均为2400000），则说明 BIOS 或用户脚本已强制锁定频率。 - 检查睿频余量：当
scaling_cur_freq接近scaling_max_freq且系统存在负载时，说明睿频功能正常生效；如果scaling_max_freq远低于 CPU 规格标称值（例如 i7-11800H 显示4000000而非4600000），则可能 BIOS 已关闭 Turbo Boost，或 RAPL 功耗限制设置得过于严格。