CPU持续100%占用但无重负载任务，实为内存不足导致频繁换页和压缩解压，使CPU替内存背锅；需通过任务管理器内存页、进程页及RAMMap验证待机列表与分页行为综合判断。
当你发现CPU持续100%占用，但没在运行视频渲染、大型编译或游戏等重负载任务，同时电脑明显卡顿、鼠标转圈、切换窗口延迟严重，这很可能是内存不足触发系统频繁换页和压缩解压，反过来拖垮CPU——不是CPU真忙，而是它在替内存背锅。
先确认是不是内存真不够用
按下 Ctrl + Shift + Esc 打开任务管理器 → 切到“性能”页签 → 点左侧“内存”。重点看三行数据：【可用】、【已提交】、【已压缩】。如果“可用”低于500MB，且“已提交”数值接近或超过物理内存总量（比如你有16GB内存，“已提交”显示15.8/17.2 GB），说明系统已在透支使用虚拟内存；此时若“已压缩”又大于1.5GB，基本可以断定：内存吃紧，CPU正被拉去干压缩/解压的苦力活。
这一步不能只看“使用率”百分比——有些机器显示85%但“可用”还有2GB，那大概率是缓存占位，CPU不会因此飙高。
查进程列表里的双重线索
切回“进程”页签 → 点击“内存”列标题排序 → 拉到底部看最后几行。
如果排在末尾的进程（如 svchost.exe、dllhost.exe、rundll32.exe）内存占用异常低（几十MB甚至个位数），但它们的“CPU”列却长期维持在15%~40%，这就是典型内存压力下的副作用：系统频繁调度这些底层服务做页面交换、句柄重映射、内核池回收，它们本身不干重活，却被内存机制反复唤醒。
方法一：右键任一低内存+高CPU的svchost进程 → “转到服务” → 查看关联服务中是否有“SysMain”“Windows Search”“Dhcp”“Dnscache”，这些服务在内存紧张时会因资源争抢而陷入高频轮询状态。
方法二：在“进程”页签顶部搜索框输入 Memory Compression → 如果出现该进程且CPU占用高于10%，说明系统正在高强度启用内存压缩，此时CPU占用就是内存不足的直接镜像。
用RAMMap验证待机列表是否失控
第一步：去微软官网下载 RAMMap（Sysinternals套件，免安装绿色版）→ 以管理员身份运行。
第二步：打开后默认显示“Use Counts”视图 → 找到 Standby List 这一行 → 看右侧“Size”数值。
第三步：如果 Standby List 占用超过总物理内存的40%（例如16GB机器里显示7GB+），同时“Active”和“Modified”加起来不足4GB，说明系统把大量本该释放的缓存死锁在待机区，新程序申请内存时无法及时回收，只能靠不断压缩+换页来硬撑，CPU自然被拖进泥潭。
注意：不要直接点RAMMap里的“Empty Standby List”按钮清空——这会瞬间引发大量磁盘写入，反而加剧卡顿。它只是诊断工具，不是清理开关。
观察磁盘活动与分页文件行为
回到任务管理器 → “性能”页签 → 点左侧“磁盘” → 看右上角“活跃时间”是否长期维持在90%以上，同时下方“读取(KB/s)”和“写入(KB/s)”数值持续跳动（尤其写入量＞5MB/s）。
再切到“资源监视器”（任务管理器“性能”页底部点“打开资源监视器”）→ “内存”页签 → 拉到最下方“物理内存”区域 → 查看“分页”相关字段：【硬错误/秒】 若持续高于50，说明程序频繁访问已被换出到页面文件的内存页，CPU必须中断当前任务去加载，这是内存不足导致CPU高占用的铁证。
