电脑越用越慢怎么办？开机耗时、启动项、硬盘健康、温度四步的第一小时体检

「第一小时体检」指的是这么一件事：不装任何第三方"加速"软件，只用 Windows 自带的读取口，在一个小时里给开机耗时、启动项、硬盘健康、温度四件事各拿到一个能复跑对账的数字。它跟跑分的区别在于每一步都先确认一件事——这个读数在你当前的权限下到底能不能读到。微软官方文档里确实有一批很好用的体检入口（事件日志、存储 cmdlet、性能计数器、powercfg），但其中一半要求管理员权限，网上抄来的命令常常把这两类混在一起写，结果就是普通用户跑出一片红色报错，误以为机器"病了"。本文把四步按"标准用户能做到哪、做不到的是哪一步"重新划了一遍线，所有数字来自一台实机，全程用标准用户身份执行并留存了输出。

信息核验时点：2026-11-03（Windows 11 当前正式版 26H2，正式版于 2026-09-29 推出，最新内部版本 26300.9818；Windows 10 版本 22H2 已于 2025-10-14 终止支持，扩展安全更新计划内最新内部版本为 19045.7811；文中四步的全部读数——7 组开关机事件的成对时间线、6 条启动项与 68 个自动启动服务与 155 个计划任务、三块物理盘的介质与健康状态、TRIM 开关的两次采样、热区计数器的两次独立采样——均在 Windows 10 专业版 19045.6466 的实机上以标准用户身份执行并留存输出；引用的微软文档页面均标注了更新时间）

体检开始前，先把"慢"拆成三段

一句话定义：开机慢指从按下电源键到桌面可操作这段时间变长；用着用着变慢指登录后一段时间内响应逐渐劣化；特定动作慢只出现在打开某个程序、存某个文件的时候。三者混在一句话里，是绝大多数"电脑越用越慢"的求助帖没法被解决的原因——它们的读数位置完全不同。

三段对应三个地方。第一段在固件与引导：BIOS 自检、硬盘初始化、引导加载，这一段 Windows 日志里只留下"上一个记录是关闭、下一个记录是启动"两个点。第二段在内核与会话恢复：驱动加载、服务启动，这一段官方给的是那个需要管理员权限的性能日志通道。第三段才是普通用户真正能看清的一段——用户登录后的启动项、计划任务、自启动服务，以及此后逐步累积的内存与磁盘占用。

在开始量之前，还有一件事必须先把口径钉住，否则量到的数字没有意义：这台机器开没开快速启动。

微软在「快速启动会导致 Windows 10 或 Windows 8.1 中的休眠或关闭失败」这篇故障排除文档（原始 KB 数 3211190，页面最近更新 2026-02-12）里给了三句决定性的话，逐字是：「在 Windows 中默认启用快速启动」「不建议禁用快速启动」「快速启动设置不适用于重启」。同页还解释了机制：「在快速启动期间，内核会话不会关闭，但它处于休眠状态。Windows 通过将内核会话和设备驱动程序（系统信息）保存到磁盘上的休眠（hiberfil.sys）文件，而不是在关闭计算机时将其关闭来执行此操作。」

这三句合起来给体检定了两条规矩：

1. 用"点关机、再按电源键"量出来的开机时间，是被 hiberfil.sys 恢复加速过的，它衡量的是"这台机器的休眠文件恢复得快不快"，跟"系统装得干不干净"关系很弱。
2. 想要一个可比较的完整启动周期，应该用重启；官方说法是重启会走完整启动周期、不带那套休眠性能改进，理由是"重启计算机时，这通常意味着你想要全新的 Windows 状态，因为已安装驱动程序或已替换的 Windows 元素，在完全重启的情况下无法替换"。
3. 反过来，如果目的就是让这一次关闭完全不加速，官方给的是命令行：Shutdown /s /t 0（用 Shutdown.exe 时完全关闭是默认设置），要混合关闭则显式写 Shutdown /s /hybrid /t 0。

本机对照：HiberbootEnabled = 1，与官方"默认启用"一致；所以下面这条时间线，全部取自带 1074 记录"重启"的那几次，而不是关机再开机。

第一步：开机耗时到底怎么量？

结论先给：标准用户能拿到"关闭到内核启动"这一段的秒级时间线，拿不到"各阶段耗时"的分解；分解数据在官方那个性能日志通道里，要管理员。

能量到的这一段，来自系统日志里的一串事件。微软「使用系统事件日志排查意外重启问题」（页面最近更新 2026-02-12）逐字列了每条的含义：事件 ID 12（来源 Kernel-General）"操作系统已在系统时间 日期时间 启动"、13（同来源）"操作系统将在系统时间 日期时间 关闭"、6005（来源 EventLog）"事件日志服务已启动"、6009"Microsoft (R) Windows (R) 加一段系统版本文字"，另外用 41 / 1074 / 6008 判定这次重启是正常还是意外，用 19 / 1001 / 7045 找重启原因。同页有一条很容易被忽略的注意事项，原话是：「事件 ID 编号可能与不同的源相关联，因此请确保根据相关源进行筛选」——同一串数字在不同来源上挂着不同含义，筛选必须同时带上来源。

本机的取法就一条命令（只读）：

Get-WinEvent -FilterHashtable @{LogName='System';
        Id=12,13,6005,6006,6008,6009,41,1074} -MaxEvents 40 |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-Table -AutoSize -Wrap

取回来 7 组成对读数，本机这台 i3-8100 + NVMe 固态的系统盘：

这组数字的读法有三层。第一层是它本身就是基线：13 到 16 秒这个区间覆盖了按下去到内核记"我起来了"的全部时间，包括固件自检；哪一天这个值涨到 40 秒，就是这一段出了问题，而这一段出问题通常跟启动项无关。第二层是成对出现才有意义：ID 13 到 ID 12 的间隔只在"重启"场景下才等于开机耗时，如果 1074 那条写的是"关闭电源"（本机 10-26 那次就是），中间隔了几个小时，就不能当开机耗时。第三层是判"意外"：官方口径里，正常重启的典型序列是 1074 后面跟 13 和 6009，而 41 和 6008 表示意外——本机在最近 40 条匹配事件里读到 Kernel-Power 41 共 1 条，没有出现 6008，属于"重启前没完全关闭"那一类记录，不构成故障结论。

本机 1074 的原文很能说明"谁干的"这类问题：

进程 C:\Windows\System32\RuntimeBroker.exe (DESKTOP-OMN553D) 由于以下原因
已代表用户 DESKTOP-OMN553D\HKC 启动计算机 DESKTOP-OMN553D 的 重启:
其他(计划外) 原因代码: 0x0 关机类型: 重启 注释:

同一台机器上，10-28 那次的进程名是 C:\WINDOWS\Explorer.EXE，10-26 那次的关机类型是"关闭电源"。也就是开始菜单里点"重启"和点"关机"，会留下进程名与类型都不同的记录，这就是官方那句"要按来源筛选"的实际含义。顺带一提，6009 那一行 Microsoft (R) Windows (R) 10.00. 19045 Multiprocessor Free 是标准用户确认自己内部版本最省事的办法，不用去设置页翻。

两个要避开的坑。

一是别把 WMI 的时间和事件时间互相印证。本机 Win32_OperatingSystem.LastBootUpTime 是 11-02 19:34:55，同一次启动的 ID 12 是 19:34:57，差 2 秒——它们记录的不是同一个点，一个是操作系统对象的属性、一个是内核写的日志，拿其中一个去"校验"另一个只会得出"日志不准"的假结论。

二是阶段分解确实拿不到。Windows 自己留了一条按启动阶段记时的通道，全名 Microsoft-Windows-Diagnostics-Performance/Operational，在事件查看器里位于「应用程序和服务日志 > Microsoft > Windows > Diagnostics-Performance > 操作」。本机以标准用户查它的结果是：通道存在且 enabled: true、日志文件在 %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Diagnostics-Performance%4Operational.evtx（这两项由 wevtutil gl 读到），但同一句命令紧接着给出 isolation: System，而它的通道安全描述符逐字是 O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x5;;;LS)(A;;0x5;;;NS)(A;;0x1;;;SU)——授权项只发给本机系统、内置管理员、本地服务、网络服务、帐户管理员这五个身份，既没有内置用户也没有经过身份验证的用户，另外两条还是对匿名与来宾的显式拒绝。所以 Get-WinEvent 取这条通道时返回的是「尝试执行未经授权的操作」。"哪个服务、哪个驱动拖慢了几秒"这一层，必须用管理员权限打开事件查看器才有数，这是体检第一步真正的权限边界。

那一步之内还能顺手看一眼的是崩溃转储。第一步引用的那份意外重启文档里，事件 ID 1001 的来源是 WER-SystemErrorReporting，说明原文是"计算机已从 bug 检查重新启动，转储保存在 C:\Windows\MEMORY.DMP"——一台"某天开始开机变慢"的机器，完全有可能只是崩溃后的转储写在了启动路径上。本机把筛选窗口放宽到最近 400 条、并把 1001 和 7045 一起加进 ID 列表后：1001 一条都没有，6008 出现 1 条（比上面表格里那 7 组更早的一次），C:\Windows\MEMORY.DMP 与 C:\Windows\Minidump 目录都不存在。转储这条解释在本机当场排除。

第二步：启动项为什么要查四个入口？

结论先给：只看任务管理器"启动应用"那一屏，一定会漏。原因很直白——那一屏只覆盖注册表 Run 键与两个启动文件夹，而登录时能自己起东西的地方至少有六类：Run 键（三个不同位置）、启动文件夹（两个不同目录）、计划任务的登录触发器、自动启动服务、以及打包应用自带的启动任务。

微软「在 Windows 中配置启动应用程序」把界面入口和判据都写清了：设置 > 应用 > 启动，或者右键"开始"选任务管理器、切到"启动应用"选项卡。这一页最有价值的是"启动影响"五档的官方数值判据，逐字是：

• 低：CPU 占用小于 300 毫秒，且磁盘读取小于 292 KB；
• 中等：CPU 占用小于 1 秒但大于 300 毫秒，或者磁盘读取小于 3 MB 但大于 292 KB；
• 高：CPU 占用大于 1 秒，或磁盘读取大于 3 MB；
• 无：该应用已被禁用；
• 未测量：没有可测量的数据，且该应用处于启用状态。

最后两档是体检里最容易误读的："无"不是"没影响"而是"已经关了"，"未测量"更不是"影响很小"而是根本没测到数据——一个还没被系统采样的自启动项，可以堂而皇之地挂在启动应用列表里顶着"未测量"。

第二处判据是位置。同一页列了三处 Run 键，注意它把 32 位那处也单独列了出来：HKCU\Software\Microsoft\Windows\CurrentVersion\Run、HKLM\Software\Microsoft\Windows\CurrentVersion\Run，以及 HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run；启动文件夹则是 shell:startup 对应当前用户的 %userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup、shell:common startup 对应 %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup。

本机把这几处挨个读了一遍，结果很能说明"只查两处会漏"：

Get-CimInstance Win32_StartupCommand |
    Select-Object Name, Command, Location | Format-Table -AutoSize -Wrap
Get-ItemProperty 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run'

• Win32_StartupCommand 视图给出 6 条：截图工具 LiteSnap 与 Edge 的自启动条目在用户 Run 键里，火绒托盘、Realtek 音频服务、安全健康图标在机器级 Run 键里，RustDesk 的托盘快捷方式在公共启动文件夹里。
• 当前用户的启动文件夹是 0 项，公共启动文件夹 1 项。
• Wow6432Node 那处真有一条：DBSvr_SPDB.exe（某银行的安全输入程序，同批还有一个作者不是微软的登录触发计划任务）。这一条不在上面 6 条里——因为 Win32_StartupCommand 的机器级视图只映射了标准那个 Run 键。只查 HKLM\...\Run 和 HKCU\...\Run，32 位软件的自启动就会整条漏掉，这条经验在本机是可复现的。

第三处判据是"谁在登录时被唤醒"。本机 Get-ScheduledTask 的总数是 155 个、其中 125 个已启用、123 个处于 Ready；带登录触发器且未禁用的 19 个，作者不是微软的 8 个。服务侧是 197 个手动、68 个自动、11 个禁用，而这 68 个自动启动服务里，二进制文件不在 %windir% 下的有 6 个（浏览器与 Google 更新服务各若干、杀软守护进程、两个远程控制软件的服务）。这 6 个才是"我明明没开几个软件，登录却要多等十几秒"的典型来源，而它们在任务管理器的启动应用页上一个都不会出现。

Get-CimInstance Win32_Service -Filter 'StartMode="Auto" and State!="Stopped"' |
    Where-Object { $_.PathName -notmatch '^\S+\\(?:Windows|winnt)' } |
    Select-Object Name, State, PathName

（上面这条本机实际用的筛选是"PathName 不在系统目录"，写法按自己环境调整；判据只有一条：自动启动、且程序体在 Program Files 或别处。）

关于"到底禁用哪些"，官方的做法不是逐个凭感觉关，而是「如何在 Windows 中执行干净启动」那篇给的两步：系统配置（msconfig）的"服务"选项卡先勾上"隐藏所有 Microsoft 服务"再点"全部禁用"，然后到"启动"选项卡点"打开任务管理器"，在"启动应用"里把每一项逐个禁用；官方那句提醒要原样记住——"隐藏所有 Microsoft 服务"这一步不能省，否则禁用掉系统服务会让机器进不起或功能残缺。定位元凶用的是官方的二分法：把项目分成两半，只启用一半重启一次，看是否还慢，逐步把范围缩小到单个条目，而不是全关再全开赌一次。

两处需要谨慎但网上教程特别爱教的地方：

其一，任务管理器里那个"启动影响"背后的抑制标记存在注册表 ...\Explorer\StartupApproved\Run 与 ...\StartupApproved\StartupFolder 两个子键下，本机读到的原始字节是 LiteSnap 那条 02 00 00 00、SecurityHealth 那条 04 00 00 00。微软没有公开这个二进制的格式，所以正确的做法只有一种：在界面里点开关，别手写这串值。

其二，设置里禁用某项后如果开机弹"找不到此应用"，官方解释是应用可能已不在控制面板的程序列表里、或快捷方式与路径已不存在——这属于卸载残留，不是"启动项生效失败"。这类清理本站另一篇开始菜单搜不到已装软件的那篇里也碰到过同一批注册表位置，可以对着看。

第三步：硬盘健康能读到的与必须管理员的

结论先给：标准用户能读到"盘是不是坏的、TRIM 开没开、剩余空间够不够整理"这三件事；读不到"寿命余量、温度、累计读写错误"——后者要管理员。

能读的那一头，官方 cmdlet 是 Get-PhysicalDisk（模块 Storage）。它的描述逐字是："The Get-PhysicalDisk cmdlet gets a list of all PhysicalDisk objects visible across any available Storage Management Providers"，示例输出的列正好就是体检要看的四列：FriendlyName、OperationalStatus、HealthStatus、Usage；同页还注明"需要存储管理提供程序才能管理物理磁盘"。本机三条读数：

配套两条也在同一权限下可用：Get-Volume（本机 9 个卷，含 C 到 H，NTFS 全部 Healthy，唯一的 exFAT 与 FAT 卷也 Healthy）、Get-StorageSubSystem（返回 Healthy）。这三条合起来能给出硬盘健康的第一判断：Windows 的存储栈没有把任何一块盘标成 Warning。这一步真正的用处是把"越用越慢"和"盘正在坏"分开——如果这里出现 Warning/Unhealthy，体检就该当场中断，先做备份再谈优化。

第二件事是 TRIM。官方写法就是查询：

fsutil behavior query DisableDeleteNotify

本机返回 NTFS DisableDeleteNotify = 0 (已禁用)、ReFS DisableDeleteNotify = 0 (已禁用)，普通权限即可读。这里的数值方向是反的，微软「fsutil behavior」的文档原话：disabledeletenotify 是「Disables (1) or enables (0) delete notifications」，也就是 0 才代表"删除通知（TRIM）开着"；同页还列了四条对体检有用的定论：「NTFS 默认启用 trim，除非管理员禁用它」「ReFS v2 默认禁用 trim，ReFS v1 默认启用」「若硬盘或 SAN 报告不支持 trim，则它们不会收到 trim 通知」「启用或禁用不需要重启，trim 在下一次 unmap 命令时生效」。文档 Remarks 末尾还留了一句反向提醒，值得抄下来：「某些设备在开启删除通知功能时可能会遇到性能下降，此时可用 disabledeletenotify 关闭通知」——所以 TRIM 不是"越开越有利"的开关，而是一项默认就该是 0、除非有具体设备问题才去动的设置。

第三件事是"剩余空间够不够整理"。微软「defrag」页（ms.date 2023-09-28、更新于 2026-02-16）有一句被普遍忽略的量化前提：「A volume must have at least 15% free space for defrag to completely and adequately defragment it」，不足时只能部分整理，因为这空间被当作排序区用。本机按这一判据过一遍，就现出一个真问题：系统盘 178.2 GB 用了 69.4 GB、剩 108.8 GB，余量充足；而那块 6 TB 机械盘（卷标签"视频"）总 4561 GB、只剩 211.3 GB，空闲比例约 4.6%，已经低于官方那 15% 的门槛。这块盘上任何"碎片整理"都不会达到官方说的"完整"效果。C 盘红了要怎么腾空间，本站另有一篇专门讲「C 盘红了怎么办」，跟这一步是衔接的。

必须管理员的那一头，本机全部撞墙，报错原文值得留着：

defrag C: /A
→ 存储优化程序无法启动，因为你没有足够的权限执行该操作。 (0x89000024)
Get-StorageReliabilityCounter -PhysicalDisk ...
→ PermissionDenied / MI_RESULT 2
fsutil fsinfo volumeinfo C:
→ 错误:  拒绝访问。

defrag 那个报错在官方文档里有出处，该页第一行权限说明逐字是：「Membership in the local Administrators group, or equivalent, is the minimum required to run this command.」

Get-StorageReliabilityCounter 这一头有点意思：它的官方文档把字段列得很全（Temperature、TemperatureMax、Wear、PowerOnHours、LoadUnloadCycleCount 与其上限、StartStopCycleCount 与其上限、ReadErrorsCorrected/Total/Uncorrected、WriteErrorsCorrected/Total/Uncorrected、ManufactureDate），描述是"这些计数器包括设备温度、错误、磨损与使用时长等信息"，但通篇没有写权限要求，本机标准用户就是拿不到。也就是说"能不能读到"这件事只能自己试，别指望文档里有。还有一处细节要记住，避免跟第四步的单位混起来：官方示例输出里 Temperature : 28、TemperatureMax : 68 用的是摄氏度，而热区计数器用的是开尔文。

defrag 那页的"计划任务"一节，是硬盘体检里最实用的一段官方定论，值得整段转述：碎片整理作为维护任务运行，通常每周一次；对 SSD 的策略是「传统碎片整理（含 retrim），每月一次」，而且改计划任务的频率不会改变 SSD 每月一次这个节奏；如果跳过分析，"优化驱动器"界面里的上次运行时间可能长达一个月没有更新；该任务不会唤醒电脑、电脑在用电池时不运行。这三条能当场废掉两类常见焦虑："我的 SSD 上次整理是 20 天前，是不是没在维护"（正常）、"我把它改成每天，SSD 会不会更耐用"（不会，节奏不变）。

本机对这一段的补充读数是普通权限的 Get-ScheduledTask：\Microsoft\Windows\Defrag\ScheduledDefrag 存在且状态 Ready（作者 Microsoft Corporation，但 LastRunTime 在标准用户下读不到，返回空——这正好印证了官方那句"上次运行时间可能是空的或很旧"）；同批 \Microsoft\Windows\DiskCleanup\SilentCleanup Ready、\Microsoft\Windows\DiskDiagnostic\Microsoft-Windows-DiskDiagnosticDataCollector Ready、而 DiskDiagnosticResolver 是 Disabled（默认状态）。顺带一个通用结论：想判断"系统的自动维护到底还在不在跑"，读这几个任务的状态比读任何第三方"优化软件"的日志可靠。

另外，网上很多教程还在用 wmic diskdrive get status。本机这台 Windows 10 上 C:\WINDOWS\System32\Wbem\WMIC.exe 确实还在、普通权限能跑、三块盘都回 OK，但微软「wmic」参考页的 Important 框逐字写着：「The WMI command-line (WMIC) utility is deprecated as of Windows 10, version 21H1, and as of the 21H1 semi-annual channel release of Windows Server. This utility is superseded by Windows PowerShell for WMI……This deprecation applies only to the WMIC utility; Windows Management Instrumentation (WMI) itself is not affected.」（该页 ms.date 2025-05-19、更新于 2026-02-16）。所以这条命令在体检里的定位应该是"老机器上的备用读数口"，主线要走 Get-PhysicalDisk——工具还能用和被弃用是两件事，别把后者当成前者不存在，也别把前者当成后者没发生。

至于 SMART 里那几项真正预示故障的属性（05 重分配扇区、C5 待定扇区、C6 不可纠正扇区）与"烤机后看温度回落"的做法，本文不重复：本站 图吧工具箱 2026.08 正式版全解读 已经把硬件检测项和 SMART 读法逐项写过，DiskGenius 的分区与数据恢复侧在 DiskGenius 6.2 实用指南。四步体检的作用是先用系统自带口确认嫌疑在哪一段，确认到硬盘这一段再上专项工具。

第四步：温度和降频，为什么不能抄网上那条 WMI 命令？

先给结论：网上流传最广的那条读温度的 WMI 命令，在本机两种写法都不通；标准用户能拿到、并且微软有公开文档的温度读数，是性能计数器里的 ACPI 热区那一组。

网上常见的写法是取 MSAcpi_ThermalZoneTemperature 这个类再换算成摄氏度。本机的实测结果是：把它放在 root/cimv2 下取，报「无效类」——这个类压根不在默认命名空间里；换到 root/wmi，类确实列得出来（Get-CimClass 能看到 CurrentTemperature、ActiveTripPoint、CriticalTripPoint、PassiveTripPoint、ThermalStamp 这些属性），但取实例时报「拒绝访问」，因为标准用户没有这个 WMI 提供程序的读取权限。而且这一条搜不到任何微软公开文档页——用站点内检索只能回到 Win32_TemperatureProbe。也就是说：它是一个厂商实现、权限要求因机而异、没有文档的类。在没有文档的地方下判断，是体检里最不该做的事。

更绕的是官方类反而没数。微软文档里"读温度"的正式 WMI 类是 Win32_TemperatureProbe，本机取回来 2 个实例、Status 都是 OK、名称都是"数字传感器"，但CurrentReading 全部为空；Win32_Fan 有 3 个实例（同样没有可用读数），Win32_CoolingDevice 直接「无效类」。类存在、实例存在、状态 OK，三个条件同时满足也可能一个数都读不到，这是"官方支持"和"这台机器上有数据"之间的真实距离。

能用的那一条走性能计数器。微软在 Windows 硬件设计的散热要求与诊断文档里定义了这组计数器的口径：热区温度以开尔文为单位，被动限流余量（Percent passive limit）100% 表示没有进入被动节流，节流原因（Throttle reason）用位标志区分不同限流来源； ACPI 侧的热事件用的是十分之一开尔文；相关的 ETW 提供者是 Kernel-ACPI 与 Thermal-Polling，并给出各自的轮询周期。本机取法：

Get-Counter '\Thermal Zone Information(*)\*'

同一天里两次独立采样，四个读数完全一致：

\_tz.tz00  temperature                     301
\_tz.tz00  high precision temperature     3010
\_tz.tz00  % passive limit                  100
\_tz.tz00  throttle reasons                   0

301 K 换算就是 27.85 ℃，与高精度那条 3010（十分之一开尔文）对得上。这一组数字的含义比温度本身更重要：被动限流余量 100%、节流原因 0，等价于"这一刻散热没有拖性能"；反过来说，如果哪一次看到 % passive limit 掉到 100 以下、Throttle Reasons 不再是 0，那就是平台已经主动压性能了，此时"越用越慢"就有了散热这条解释。

再看节流事件。本机 Microsoft-Windows-Kernel-Power/Thermal-Operational 这条通道存在、enabled: true、记录数 0；Diagnostics-Performance/Operational 存在（读取要管理员）。也就是说这台桌面机到今天没有记过一次热事件。

判降频还有一处必须避开的坑：Win32_Processor 的 CurrentClockSpeed 不能用来判断有没有降频。本机 i3-8100 的 CurrentClockSpeed 是 3600、MaxClockSpeed 也是 3600，而同一时刻 LoadPercentage 是 12——那个"当前频率"是静态填报值，不随实时功耗与温度变化。要看真实频率状态，走同一份硬件文档推荐的处理器性能计数器：

Get-Counter '\Processor Information(*)\% of Maximum Frequency'

本机四个逻辑核加 _total 六个实例全是 99，与热区那组"没有限流"互相印证。这一步的完整判断于是是三句话：热区没进被动限流、节流原因为 0、核频率还在标称值附近——三个同时成立，才能干净地把"温度"从嫌疑名单里划掉。

笔记本用户在这里会多撞一次墙。powercfg 那三份报告（/energy、/batteryreport、/sleepstudy、以及 /systempowerreport）里，微软在 Windows 硬件设计的 powercfg 命令行文档对 /systempowerreport（别名 /spr）的说明逐字是「为系统在过去三天的系统电源转换生成报告……此命令需要管理员特权，并且必须在权限提升的命令提示符下执行」；/energy 则要求在计算机空闲、没有打开程序或文档时跑，默认采样 60 秒。本机在标准用户下三条全部被拒，报错原文是「此命令需要管理员权限，并且必须从提升的命令提示符中执行」，而 /thermalconstraints 在 Windows 10 19045 上直接回「参数无效」。电池与新式待机的报告怎么逐项读，本站另有两篇分别讲 powercfg batteryreport 与 srumutil 和 现代待机 S0 与 sleepstudy，那两篇处理的是"掉电与唤醒质量"，本文这一步处理的是"性能有没有被散热压住"，读数位置不同。

最后一个边界要说清：热区计数器给的是平台定义的热区温度，不是 CPU 封装温度、不是核心温度，也不包含显卡与 SSD 的温度。四步体检在温度这一步的产出是"有没有被限流"这个二值判断，要具体到"哪个传感器 85 ℃"就得上厂商工具或图吧工具箱那类硬件检测集合。

四步读数合起来怎么看？一张对照表

单看一步的读数没有结论意义，四步合起来才有。下面是本机这次的完整判定链，也是照着做时应当填的表：

这台机器读下来的落点很清楚：引导段没恶化、盘没坏、TRIM 开着、散热没有限流，四步里有三步是绿的，所以"越用越慢"的嫌疑只剩登录后那一段（自启动的服务与常驻程序）以及一个本文四步之外的变量——内存被吃掉之后开始用页面文件。本机这一项也有数：页面文件由系统自动管理，C:\pagefile.sys 分配 2560 MB、当前使用 40 MB、峰值 42 MB，16 GB 物理内存空闲 8.5 GB 左右，进程总数 230 个，工作集最大的一组是编辑器自己的几个进程（674 MB、486 MB、401 MB）。也就是说这台机器还没到用页面文件的程度，"越用越慢"更像是常驻程序的累积占用与切换成本，而不是内存不足。

顺带把"系统版本"这个背景变量也钉一下，因为它决定还有没有安全更新可拿。微软 Windows 11 发布信息页给出的正式发布频道表（最新修订日期 2026-10-28）：26H2 上市 2026-09-29、家庭与专业版更新终止 2028-10-10、最新内部版本 26300.9818；25H2 上市 2025-09-30、更新终止 2027-10-12、最新内部版本 26200.9818；24H2 的家庭与专业版一栏已经写着"更新终止"；页首还有一句适用于所有版本的话——功能更新每年下半年发布，家庭/专业/专业工作站/专业教育版有 24 个月支持、企业与教育版 36 个月。Windows 10 那侧，发布信息页第一句是「Windows 10 将于 2025 年 10 月 14 日终止支持」，22H2 的家庭/专业与企业/教育两栏都是"更新终止"，只有"ESU 的最新更新"一栏给到 2026-10 OOB、最新内部版本 19045.7811。本机 19045.6466 就落在这个背景里——体检里所有"最新版"的对照，都是拿这两个版本号做基准的。

哪些体检动作必须管理员权限？

把权限线画清楚，是这篇跟多数"优化教程"最大的差别，也是本机逐条撞出来的结果。下表全部是实测，不是推测。

标准用户就能读、可以直接进日常体检的：系统日志里那串开关机与重启事件；启动项的三个 Run 键、两个启动文件夹、计划任务与服务清单；Get-PhysicalDisk、Get-Volume、Get-StorageSubSystem 的健康状态；fsutil behavior query DisableDeleteNotify；Get-Counter 的热区与处理器频率计数器；Get-CimClass 的属性表；以及设置页里的启动开关与任务管理器的"启动应用"页。

本机在标准用户下明确被拒的（报错都留了原文）：

这里有一条方法论上的提醒：官方文档对"需要管理员"的写法并不统一。defrag 写在页首的权限说明里、powercfg /systempowerreport 写在功能描述里，而 Get-StorageReliabilityCounter 通篇没写，只有在实测里才现形。所以体检时"读不到"要先判"权限不够"再判"功能缺失"——把权限报错当成机器故障，是这类文章最容易造成的次生焦虑。反过来也一样：Get-StorageReliabilityCounter 里有的字段会整条是空的——官方文档自己的示例输出里 Wear 那一栏就没有值，所以某个字段读不到数不等于"这项指标正常"，只等于这块盘没把这一项报上来。

网上那几个"提速"操作，官方文档里是怎么写的？

体检做完了，接着是"要不要动手"。这一节只讲官方口径与原话，因为这几个操作在被转述时失真得最厉害。

关掉 SysMain（原名 Superfetch）。 网传的这套做法通常是一整套动作：运行 services.msc、找到 SysMain、点停止、把启动类型改成禁用、删除 %systemroot%\Prefetch 下的文件、再重启。本站把微软文档站现存关于这个服务的页面逐条打开对过，能查到的那页标题是「SuperFetch（SysMain）服务使用 CPU」（适用于 Windows 7 Service Pack 1，原始知识库编号 2723033，页面最近更新 2026-10-14），它讲的是另一件事：某个用 /LARGEADDRESSAWARE:NO 这个编译选项打出来的 64 位程序，会让承载 SysMain 的 svchost 出现一到两分钟的 CPU 占用峰值，官方给的解决办法是让开发方别用这个编译选项，通篇没有让你禁用这个服务。也就是说"禁用 SysMain 加删 Prefetch"这套步骤，在本次能打开的官方文档里找不到对应页面——这不是说它一定无效，而是说它没有官方口径给你兜底。本机这条链子的状态是：SysMain 服务 Running、启动类型 Automatic，EnablePrefetcher 的值是 3，EnableSuperfetch 这个值在本机根本没有设置（走默认）。也就是说"网上让你去改 EnableSuperfetch"的那批教程，在这台机器上连改的对象都不存在——这不代表教程全错，只代表改之前先读一下本机有没有这个值。判断该不该动 SysMain，顺序是先按第二节确认它有没有真的拖慢启动，再确认自己愿意付"重启后头几次开机要重新预读"这个代价；体检阶段的答案是不动它。

关闭快速启动。 官方原话是「不建议禁用快速启动」。它换来的好处是每次都走完整启动周期（某些驱动更新、某些需要全新内核状态的场景会因此变正常），代价是把那段被 hiberfil.sys 加速的省时间还给固件与驱动加载。体检里的正确用法不是"关掉它提速"，而是知道它开着，从而不把关机再开机的秒数当成冷启动数据。

给 SSD 做碎片整理。 官方 defrag 页把节奏写死了：SSD 的传统碎片整理与 retrim 每月一次，改计划任务频率不改变每月一次的节奏；手动跑一次传统整理之后，下一次计划任务会做分析与 retrim、而跳过那次传统整理。所以"每周给 SSD 整理一次"这类做法在官方口径下既不必要、也不会被系统接受得更频繁。真要手动跑，还得先满足那条 15% 空闲空间的前提。

清理注册表、删启动项残留。 这批动作在本篇引用的微软文档里没有对应条目，也就没有"官方推荐"这一说。要清自启动，用设置页与任务管理器；要看卸载残留，用第四节的干净启动二分法定位，而不是拿"清理工具"整片删键。

装一个"加速/内存整理"软件常驻。 这一步在本机有个反例可看：这台机器工作集排前的进程里，除编辑器与浏览器之外就是远程控制与杀软的常驻组件，而 68 个自动启动服务里有 6 个的程序体不在系统目录。体检第一步到第二步的意义，就是把"谁常驻"变成可见的清单；清单摆出来之后，绝大多数情况该做的是把不需要的条目在界面里关掉，而不是再叠一层常驻软件。本站 Windows 自带工具够用吗 那篇把截图、录屏、计算、便笺、备份逐项对照过，结论与这一节的取向一致。

卸载内置应用。 这个动作有确定收益（少几个后台），也有确定的坑（重装回来的路径不统一）。它属于"第二步之后的可选动作"，不是一小时体检本身，具体命令写法与恢复方法在 用 PowerShell 卸载与重装 Windows 内置应用。

常见问题 FAQ

教程让我在事件查看器里筛启动性能事件，为什么一条都看不到？

因为那条日志默认不给普通用户读，而不是你的机器没记。位置是「应用程序和服务日志 > Microsoft > Windows > Diagnostics-Performance > 操作」。本机在标准用户下用 Get-WinEvent 直接取这条通道，返回的是「尝试执行未经授权的操作」，而 wevtutil gl 显示这条通道 enabled: true、isolation: System，安全描述符的授权项里没有普通用户（第一步贴了那条描述符原文）。正确的做法有两种：用管理员身份打开事件查看器再看，或者接受标准用户能拿到的那一段（系统日志里 13、12、6005 的成对时间戳），后者足够回答"引导段有没有变慢"。

开机 15 秒算快还是算慢？

单看这个数字没有意义，要跟自己的历史比。本机的 7 组读数落在 13 到 16 秒，这是"上一次内核关闭记录到下一次内核启动记录"，包含固件自检；同一台机器如果哪天涨到 40 秒，那才是异常信号，而 15 秒在一台 NVMe 系统的桌面机上属于正常区间。更重要的是这个数的口径：如果这次是"关机再开机"而快速启动是开着的（本机 HiberbootEnabled = 1），那你量到的是从休眠文件恢复内核会话，官方明确这套加速不适用于重启，所以两个数字彼此不可比。想要可比的基线，固定用"重启"这一动作，取三四次去中间值。

任务管理器显示启动影响是"无"，是不是就不用管了？

"无"是官方定义的该应用已被禁用这一档，不是"没有影响"。同一套定义里还有一档叫未测量——没有可测量数据、且应用处于启用状态——那一档才是真正需要留意的，因为它意味着系统没采到数、你却让它每次登录都自启。而且启动影响这一列只覆盖 Run 键与启动文件夹里的条目，不覆盖服务与计划任务：本机 6 条启动项之外，还有 68 个自动启动服务（6 个程序体不在系统目录）与 19 个带登录触发器的计划任务，这些在任务管理器那一屏一个都不出现。

硬盘一切健康，为什么机器还是慢？

因为"健康"只排除了坏盘这一种可能，排除不了"用不了"。本机的例子很具体：三块盘全部 Healthy、TRIM 是启用状态（值 0），但那块 6 TB 机械盘只剩 211.3 GB，卷总容量 4561 GB，空闲比例约 4.6%，低于官方 defrag 文档给出的"至少 15% 空闲空间才能完整整理"的前提。盘是好的，空间布局已经不利于整理，接近满盘的大容量机械盘在实际读写时的表现会明显劣化——这类问题在健康状态里是看不出来的，必须在第三步就把每个卷的剩余比例一起读。腾空间的专项做法在 C 盘红了怎么办，那篇按"能腾出多少"逐项排过顺序。

这套四步体检要多久？

照着本文的命令做，20 到 30 分钟能出全部标准用户可读的读数；剩下半小时留给两件必须重启动作的事——按官方干净启动流程做一次二分定位，以及把可疑的自动启动服务关掉之后再取一次内核启动到事件日志服务就绪的秒数。真正的瓶颈从来不是命令，是"要不要重启一次"。

这些命令会不会改我的机器？

不会。本文所有读数动作全是只读的：Get-WinEvent、Get-CimInstance、Get-ItemProperty、Get-ScheduledTask、Get-PhysicalDisk、Get-Volume、Get-StorageReliabilityCounter、Get-Counter、fsutil behavior query、wevtutil gl。会写系统的动作只有四类，都在正文里明确标了权限或官方警告：改启动类型（服务）、禁用启动项（界面）、defrag 与整理（官方要求 Administrators）、删除 Prefetch 目录下文件（网传做法，本文第六节说明它在现存官方文档里查不到对应页面）。体检阶段一个都不必做。

写在最后

四步体检真正交付的不是四个数字，而是一条定位结论：引导段、登录后段、磁盘、散热各有一个只属于自己的读数位置，慢在哪一段就只看那一段的证据。本机的结论是引导段 13 到 16 秒没有恶化、TRIM 开着、盘全部健康、热区没有限流，所以问题在登录后那一段的常驻程序上，而且还没有触发页面文件——下一步该做的是按官方干净启动流程做二分，而不是关 SysMain、删 Prefetch 或者给 SSD 加一次碎片整理。

还有两件事值得留在结论里。一是权限是分层的，报错不等于故障：这篇里那些"拒绝访问""未经授权""0x89000024"全是正常边界，微软对 defrag 与 powercfg /systempowerreport 都写明了要管理员，而对 Get-StorageReliabilityCounter 压根没写，只能实测；把这些当成机器坏了去搜，只会搜到一堆建议你再装一个工具的回答。二是版本口径要留在纸面上：Windows 11 当前正式版是 26H2（2026-09-29 推出，最新内部版本 26300.9818），24H2 的家庭与专业版已经写了"更新终止"；Windows 10 一侧官方写的是 2025 年 10 月 14 日终止支持，22H2 只剩扩展安全更新计划内的 19045.7811。一台停在已经终止支持的版本上的机器，"变慢"的第一解释应当是后台更新与安全软件，而不是那几条被反复转述的注册表优化。

想接着往下查的两条延伸路径：硬件侧（SMART 属性、烤机、传感器温度）走本站 图吧工具箱 2026.08 正式版全解读；系统分区与磁盘侧（哪些数据能安全腾走、怎么判能腾出多少）走 C 盘红了怎么办。这两篇和本文是同一套做法的两个延伸面：先让读数可见，再决定动手。

本文所有命令、事件日志与计数器读数核验于 2026-11-03，以微软官方文档与后续系统版本为准。