必须通过三步验证：1.查scaling_governor确认是否启用缩放（如ondemand）；2.比scaling_min_freq与scaling_max_freq是否可变；3.用watch实时观察scaling_cur_freq是否随负载跳变，三者缺一不可。
要确认CPU是否正在根据负载动态调整各核心频率，而不是卡死在固定频率上，必须绕过任务管理器的平均值陷阱，直接读取内核级调控状态与实时频率采样数据。
Linux系统中查看CPU频率缩放状态
该方法适用于Ubuntu、RHEL、Arch系等主流发行版，依赖内核cpufreq子系统原生接口，无需额外安装图形工具。
第一步：确认当前使用的调速器（governor）
执行命令：cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor。输出如 【ondemand】 或 【powersave】 表示频率缩放已启用；若为 performance，则频率被锁死，缩放功能实际关闭。
第二步：检查频率范围是否可变
运行：cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 与 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq。两个数值相等（例如都是2400000）说明上下限被设为同一值，缩放区间失效——这常见于BIOS中启用了“Intel SpeedStep Disable”或系统服务强制锁定频率。
第三步：观察实时频率波动
执行：watch -n 1 'cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq'。若数值随终端操作、浏览器滚动等轻负载持续跳变（如从800000 → 1600000 → 2100000），证明缩放机制正在工作；若长期静止不动，需排查是否有服务（如thermald、power-profiles-daemon）或用户脚本覆盖了默认策略。
Windows下验证大小核CPU的频率缩放行为
任务管理器显示的是所有逻辑处理器的加权平均频率，对大小核架构（如Intel 12/13/14代、AMD Ryzen 7040+）完全失真，必须用能区分核心类型的工具。
方法一：HWiNFO64逐核采样
启动HWiNFO64 → 勾选“Sensors only” → 进入主界面后展开“CPU”节点 → 展开每个“CPU Core #x”子项 → 查找“Clock”字段。性能核（P-core）频率应能在低负载时降至1.0 GHz以下，高负载单线程时跃升至5.0+ GHz；能效核（E-core）则通常维持在1.8–3.0 GHz区间。若所有核心频率始终同步且无梯度差异，说明调度器未正确识别大小核拓扑，或Windows电源计划被设为“高性能”并禁用了Core Parking。
方法二：PowerShell对比基础与当前频率
以管理员身份运行PowerShell，输入：Get-WmiObject Win32_Processor | Select-Object Name, MaxClockSpeed, CurrentClockSpeed, NumberOfCores。注意：MaxClockSpeed是硬件支持的最高睿频（单位MHz），CurrentClockSpeed是系统报告的瞬时采样值。若CurrentClockSpeed长期等于MaxClockSpeed，大概率是后台进程（如杀毒软件扫描、Windows更新服务）持续占用CPU，掩盖了缩放效果——此时应配合任务管理器的“CPU”图表观察% Usage曲线是否起伏，只有负载变化时CurrentClockSpeed才可能真实反映缩放响应。
节能分析与性能评估联动操作
真正有效的评估必须在同一负载下对比不同调速器的行为差异，不能只看静态参数。
① 切换至powersave模式并记录基线：
执行：sudo cpupower frequency-set -g powersave → 等待30秒 → 运行 stress-ng --cpu 4 --timeout 60s（模拟4核满载）→ 在另一终端持续执行 cpupower frequency-info | grep "current policy"，捕获频率爬升过程与最终稳定值。
② 切换至ondemand模式重复测试：
sudo cpupower frequency-set -g ondemand → 同样运行60秒stress-ng → 观察频率响应延迟（ondemand通常比powersave快100–300ms触发升频）和峰值高度（ondemand更激进，常逼近scaling_max_freq上限）。
③ 关键验证点：
执行 sudo cpupower idle-info，检查C-state深度是否随负载变化。若C3/C6状态计数在空闲期显著上升，说明节能路径通畅；若idle state始终卡在C1，即使governor设为powersave，实际也未进入深层休眠——此时需检查内核启动参数是否含 【intel_idle.max_cstate=1】 或BIOS中关闭了C-states。
