磁盘使用率都 100% 了，为什么只有几 MB/s？

因为磁盘处于活动状态的时间，和每秒能传输的字节数是两个不同的指标。细碎的读写和 I/O 的等待时间会让传输量不大却依然很忙。请确认目标磁盘的响应时间，以及缓慢的操作是否同时发生。

禁用 SysMain 一定会变快吗？

不能说一定会变快。请先保持常规设置，只有在怀疑与 SysMain 有关时，才在记录下原有状态之后比较临时停止与重新启动的差别。是否永久禁用，不要只凭这一次比较来决定。

Windows Search 可以停掉吗？

它会影响依赖搜索索引的搜索速度和结果的更新，所以不要把它当成第一个对策。先确认索引的进度，如果有不需要的文件夹被纳入了搜索范围，应优先考虑调整这个范围。

可以关掉 Defender 来降低磁盘使用率吗？

不建议把关闭实时保护当作日常的提速手段。请用 Microsoft Defender Antivirus 的性能分析器记录扫描的负担，查明与哪些文件或处理有关。报告中排在前面的项目，也不能就这样加入排除设置。

磁盘使用率 100% 要停掉什么才能好？──分辨 SysMain、Windows Search 与 Defender

2026年09月05日 04:00 · 更新日期: 2026年09月08日 · Go Komura · Windows 11, 性能, 故障排查, SysMain, Windows Search, Microsoft Defender, PowerShell

打开任务管理器一看，磁盘 100%。开应用慢，打字也慢。这时如果查到“禁用 SysMain”“停止 Windows Search”“关闭 Defender”这些做法，就会很想干脆全部停掉。

但这里要区分的是，“是什么在读写”和“为什么操作会被卡住”。光看任务管理器上排在前面的名字，是分不出这两者的。

本文主要面向使用 Windows 11 电脑的普通用户，说明界面数值的读法、这三个功能各自的职责，以及可以还原设置的调查步骤。界面名称和可用功能会因 Windows 的版本和管理策略而不同。需要管理员权限的操作会明确标出。出处是 2026 年 9 月 5 日确认的 Microsoft 一手资料。本文不是在特定实际设备上测量改善幅度的文章。

1. 先说结论：不要把三者一视同仁地停掉

本文建议的顺序是：观察 → 缩小范围 → 只改一处 → 还原后比较。请先保存重要文件；如果是公司统一管理的电脑，更改设置前请与管理员沟通。

功能	先看什么	首先考虑的做法
SysMain	出问题的时段是否与该服务有关	通常保持原样。只有在有依据时才比较临时停止与重新启动
Windows Search	索引的进度与搜索范围	检查是否包含了不需要搜索的文件夹
Microsoft Defender Antivirus	扫描是否与缓慢的操作重叠	在保持保护的前提下记录并分析

这张表并不是单纯按“停掉有多危险”排列的。SysMain 的职责是维持与改善系统性能，Search 是为搜索建立索引，Defender 是反恶意软件，三者各不相同。失去的功能也各不相同。¹²³

flowchart TB
    accTitle: 排查磁盘 100% 的基本顺序
    accDescr: 看到磁盘 100% 后，先观察缓慢的操作和对象，只比较一处改动并还原的顺序。
    A["磁盘 100% 与操作变慢"] --> B["记录时段与对象"]
    B --> C["尝试一个假设"]
    C --> D["还原后再次确认"]
    D --> E["只保留必要的对策"]

图 1: 在成批修改设置之前，先做出一个可供比较的状态。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 13 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 100% 既不是“容量已满”，也不是“达到最高速度”

在任务管理器的“性能”中打开目标磁盘，可以看到活动时间、读取与写入速度、平均响应时间。忙碌时间的占比和实际搬运的数据量是两回事。剩余容量够不够，也需要另外确认。

举例来说，如果每一笔处理都要等待，那么即使一直在干活，推进的数据量也不会多。这就像“一次搬一个大箱子”和“一个一个递小箱子”的区别。当读写很细碎，或者存储一侧有延迟时，即便只有几 MB/s 也可能接近 100%。Microsoft 的性能调查资料中，除了传输量之外也会确认 I/O 的响应时间。⁴

因此，“既然 100% 就说明 SSD 的速度已经跑满”和“只有几 MB/s 所以磁盘不是原因”都下结论太早。首先要把出问题的磁盘编号和驱动器号对上再看。如果 C: 和 D: 在同一块物理磁盘上，对 D: 的操作也可能与 C: 一侧的操作发生竞争。

flowchart TB
    accTitle: 观察磁盘的三个指标
    accDescr: 活动时间、传输速度、响应时间是不同的指标，要放在同一时段一起看。
    A["观察同一时段"] --> B["忙碌程度：活动时间"]
    A --> C["处理量：读写速度"]
    A --> D["等待：响应时间"]
    B --> E["与操作的迟缓相互印证"]
    C --> E
    D --> E

图 2: 光看百分比，无法区分是处理量大，还是等待时间长。

3. 最初的观察：什么时候、哪个文件上变慢

先不要停服务，用 Ctrl + Shift + Esc 打开任务管理器。给“进程”里的磁盘一列排序，同时在“性能”中确认对应的磁盘。再用 Win + R 启动 resmon.exe，在资源监视器的“磁盘”中查看进程名、文件、读取、写入和响应时间。如果能看到的信息不够，请委托管理员来调查。⁵

记录要和具体作业绑在一起，例如“开机后 3 分钟”“解压 ZIP 的过程中”“直到同步结束”。本文建议的不是只看某一瞬间的画面，而是把变慢之前、变慢期间、恢复之后放在一起比较。更新或复制正在进行、完成后就平静下来的情况，和同样一个小操作每次都长时间卡住的情况，接下来要查的东西是不同的。

另外，响应时间的平均值并不等于单次操作的最差值。不要只凭一个偶发的高数值就断定是故障，要与可重现的停顿或错误相互对照。即使 System 或 svchost.exe 排在前面，也不要只凭名字就强行结束它们。System 还牵涉内核和驱动程序的处理。⁴

flowchart TB
    accTitle: 调查中要留下的观察记录
    accDescr: 以变慢的时刻和操作为起点，记录磁盘、进程、文件以及恢复时的条件。
    A["缓慢的操作与时刻"] --> B["确认对应的磁盘"]
    B --> C["查看进程与文件"]
    C --> D["结束之后继续观察"]
    D --> E["记录恢复时的条件"]

图 3: 不只是“当时很卡”，还要留下能用来重现的记录。

4. 看到了名字，和它就是根本原因，是两回事

当一个会大量创建文件的应用在跑时，除了该应用自身的写入，还可能叠加上搜索索引的更新和安全检查。Search 会把文件的信息编入搜索索引，Defender 则会对文件和处理进行检查。²⁶

接下来是为了思考原因而举的例子。在解压软件大量创建文件的过程中，即使 Defender 的负担增加了，也不代表“只有 Defender 出了问题”。文件生成的频率、目标文件夹、存储的响应可能都在共同起作用。

反过来，因为是正规的 Windows 功能就断定它无关，同样是错的。即便是必要的功能，在实际环境中也可能成为竞争因素。我们想知道的不是谁好谁坏，而是减少哪一类处理、减少多少，才能改善自己需要的作业。

flowchart TB
    accTitle: 一项作业引发多处读写的例子
    accDescr: 大量生成文件时，若在搜索范围内则叠加索引更新，若在保护范围内则叠加检查。
    A["大量生成文件"] --> B["应用自身的写入"]
    A -.-> C["在搜索范围内则更新索引"]
    A -.-> D["在保护范围内则进行检查"]
    B --> E["可能在同一保存位置竞争"]
    C --> E
    D --> E

图 4: 虚线的处理并不表示每次一定发生，而是可供调查的候选关系。

5. SysMain：先保持原样，只在有怀疑时做临时比较

在 Microsoft 的服务一览中，SysMain 是以维持与改善系统性能为目的的服务，在那份资料里被归入不应禁用的类别。不过资料的适用对象是 Windows IoT Enterprise，并不是“所有普通 Windows 11 电脑都一定会变快”的实测保证。¹

本文不建议仅凭磁盘 100% 这一显示，就把启动类型改成“禁用”。停掉之后数字马上下降，也可能只是后台的工作变少了。还要看打开应用花的时间，以及平时的作业是否有所改善。

在任务管理器中展开服务主机的分组确认关联，只有在拿到怀疑 SysMain 的材料时，才以管理员身份做短时间的比较。停止之前，请用 services.msc 记下 SysMain 的状态和启动类型。临时停止服务，和让它下次开机也不启动，是两种不同的操作。⁷⁸

flowchart TB
    accTitle: SysMain 的临时比较与永久禁用的区别
    accDescr: 本次调查是把运行中的服务临时停止再恢复，与永久更改启动设置分开处理。
    A["确认与 SysMain 的关联"] --> B["记录原有状态"]
    B --> C["若在运行中则临时停止"]
    C --> D["比较同样的操作"]
    D --> E["重新启动并确认"]
    B -.-> F["不更改启动设置"]

图 5: 不要把“停下来看差异”和“一直禁用”混为一谈。

面向管理员：把 90 秒比较与恢复合成一段处理

下面是在以管理员身份打开的 Windows PowerShell 5.1 中整段执行的例子。它只针对本来就在运行的 SysMain，在停止后的 90 秒内到另一个窗口去试同样的作业。启动类型不做更改。

# 在管理员的 Windows PowerShell 5.1 中整段执行。
$service = Get-Service -Name SysMain -ErrorAction Stop
if ($service.Status -ne 'Running') {
    throw 'SysMain 未在运行。将不更改当前设置并退出。'
}

try {
    Stop-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Stopped', [TimeSpan]::FromSeconds(30))
    Write-Host '请在 90 秒内到另一个窗口比较同样的操作。'
    Start-Sleep -Seconds 90
}
finally {
    Start-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Running', [TimeSpan]::FromSeconds(30))
    Get-Service -Name SysMain | Select-Object Name, Status
}

finally 的作用是在正常结束或发生异常时尝试恢复。它并不能保证在强制关闭 PowerShell 窗口、结束进程或断电的情况下也能恢复。 如果中途被打断，请用 services.msc 确认状态；若按本步骤停止的 SysMain 仍处于停止状态，请把它启动起来。恢复失败时也不要放着不管，请与管理员沟通。⁹

flowchart TB
    accTitle: 结束临时停止试验时的确认
    accDescr: 正常情况下由 finally 尝试恢复，强制结束或恢复失败后要在服务界面确认状态。
    A["结束比较"] --> B{"能确认已重新启动吗"}
    B -->|"是"| C["在原有状态下再比较一次"]
    B -->|"否"| D["在服务界面确认"]
    D --> E["启动服务或与管理员沟通"]

图 6: 即使有自动恢复的代码，也不要省略最后的状态确认。

6. Windows Search：停掉之前先想清楚“你想搜什么”

Windows Search 的索引，是为了快速找到文件名和内容等信息而建立的机制。索引在创建、更新期间会产生工作量，但这也是让搜索变快的准备。²

在 Windows 11 中打开“设置”→“隐私和安全性”→“搜索 Windows”，确认索引的进度和搜索范围。如果显示名称不同，请在设置里搜索“索引”。如果有大量用不到的文件被纳入范围，可以通过“排除的文件夹”或“索引选项”中的“修改”来缩小范围。¹⁰

例如开发用电脑上的 node_modules 和构建输出，如果不需要用 Windows 的搜索来找，就是可以考虑调整的对象。但这并不是仅凭文件夹名就一律排除的建议。要先想清楚：把某个位置排除出搜索之后，那里的内容不能像以前一样被搜到，你是否会为难。 只要记录下更改前的范围，一旦搜索出问题就能还原。

这里说的“从搜索范围中排除”，和后文的“从 Defender 的保护范围中排除”是两回事。不要把两边的设置一起改。¹¹³

flowchart TB
    accTitle: 缩小搜索范围的判断
    accDescr: 确认被索引的文件夹，再依据是否需要用 Windows 搜索该位置来调整范围。
    A["确认被索引的位置"] --> B{"是搜索时需要的位置吗"}
    B -->|"需要"| C["保持在范围内"]
    B -->|"不需要"| D["记录后调整搜索范围"]
    D --> E["确认负担与搜索结果"]

图 7: 在停用整个搜索功能之前，先想想能不能减少要准备的信息量。

不要把重建当成“先按了再说的修复按钮”

重建索引是把索引重新做一遍的操作。如果它本来就在创建中，那就等于把这份工作再来一次。Microsoft 的说明中提到重建预计最多需要 24 小时左右，而在创建期间搜索结果可能不完整。¹⁰

因此，不建议仅仅因为磁盘很忙就反复重建。先确认进度和错误，在调整范围之后或搜索结果出问题等确实需要重建的场合再执行。真要执行，就接上电源、留出足够完成的时间，并把重建期间的负担与稳定状态下的负担区分开。

flowchart TB
    accTitle: 把索引重建期间与完成之后分开看
    accDescr: 重建期间存在重做的负担和暂时不完整的搜索结果，效果要在完成之后判断。
    A["确认必要性后重建"] --> B["重新建立索引的期间"]
    B --> C["等待完成"]
    C --> D["确认搜索结果与负担"]

图 8: 不要只凭刚开始重建时的忙碌程度，就判断对策成功与否。

7. Defender：不关掉保护，去查“它在检查什么”

即使 Antimalware Service Executable 或 MsMpEng.exe 很显眼，也不建议把关闭实时保护当作日常的提速手段。保护被停用期间，打开的文件和下载的文件都无法照常接受检查。就算磁盘的数字下降了，如果丢掉了必要的功能，也不能说是在相同条件下变快了。³

可以用于调查的，是 Microsoft Defender Antivirus 的性能分析器。它会记录扫描过程，把检查耗时较长的文件和相关进程整理成报告。它不是用来测量整台电脑全部磁盘延迟的工具，而是与资源监视器中看到的缓慢时段结合起来，用于查明 Defender 的检查是否有关。⁶

flowchart TB
    accTitle: 在保持保护的前提下调查 Defender 的负担
    accDescr: 保持实时保护的同时记录缓慢的操作，把扫描报告与操作时间相互对照。
    A["保持实时保护"] --> B["记录缓慢的操作"]
    B --> C["检查耗时的报告"]
    C --> D["与实际的等待时间对照"]
    D --> E["也去查文件生成等因素"]

图 9: 不是靠关掉安全功能把数字压下去，而是去看负担的内容。

面向管理员：采集记录并查看排在前面的项目

官方的前提是 Windows 10 及以上、Defender 平台 4.18.2108.X 及以上，并且需要管理员权限。如果在用别的安全产品，或者组织的管理策略限制了相关功能，就不要硬套这套步骤，请向管理员或产品支持窗口确认。¹²

下面在以管理员身份打开的 Windows PowerShell 5.1 中执行。开始记录后，到另一个窗口重现有问题的操作，再按记录端的提示用 Enter 结束。如果是日常性的问题，就把重现区间压短，不要长时间一直记录。⁶

# 在管理员的 Windows PowerShell 5.1 中执行。
Get-Command New-MpPerformanceRecording, Get-MpPerformanceReport -ErrorAction Stop |
    Select-Object Name, Source

# 使用唯一的名称，以免覆盖已有的记录。
$trace = Join-Path $env:TEMP ('Defender-' + [guid]::NewGuid().ToString('N') + '.etl')
Write-Host "记录到: $trace"
New-MpPerformanceRecording -RecordTo $trace -ErrorAction Stop

# 结束记录之后再读报告。
Get-MpPerformanceReport -Path $trace -TopFiles 10 -TopProcesses 10 -ErrorAction Stop

这里排在前面的，是在记录区间内对扫描影响最大的项目。它并不意味着“把前 10 项排除掉就能安全地变快”。Microsoft 也没有把这个分析器定位成建议排除项的工具。¹²

首先要查的是：是什么在反复重新生成这个文件、同样的作业有没有重复、能不能在应用一侧做调整。如果确实需要排除，那要由理解影响范围和保护削弱程度的管理员逐项判断。不要仅凭本文的步骤就把整个 C: 或整个用户配置文件排除掉。记录中包含文件路径和进程信息，交给外部之前请确认机密信息的处理方式。

flowchart TB
    accTitle: 从分析报告出发的调查顺序
    accDescr: 扫描负担的靠前项目只是调查的入口，要先确认生成来源与频率再考虑对策。
    A["报告中靠前的项目"] --> B["确认生成来源与频率"]
    B --> C["考虑在应用一侧改善"]
    C --> D["必要时与管理员逐项判断"]
    A -.-> E["不要直接做成排除列表"]

图 10: 报告是查原因的材料，不是可以放弃保护的文件清单。

8. 除了这三者也要看：内存与存储的状态

如果是打开很多应用时才变慢，那就同时确认任务管理器里的内存。把不在内存中的页面从存储读回来的“硬错误”可能会增加，但这并不意味着磁盘发生了物理故障。读回的来源不只是页面文件，也可能是可执行文件或内存映射文件。仅凭出现了数值，也不能断定就是内存不足。¹³

“关掉不需要的应用之后，磁盘的等待和操作是否一起改善”是值得比较的。另一方面，不建议用禁用页面文件的方式来消除读写。那会降低可提交内存的上限，可能招致别的失败或不稳定。¹⁴

flowchart TB
    accTitle: 硬错误的读法
    accDescr: 硬错误是把不在内存中的页面从磁盘读回的处理，不是断定物理故障或内存不足的指标。
    A["需要的页面不在内存中"] --> B["从文件读回"]
    B --> C["产生磁盘 I/O"]
    C --> D["比较内存使用量与操作"]
    B -.-> E["并不意味着物理故障"]

图 11: 不要只凭“硬错误”这个名字，就认定是故障或页面文件的问题。

另外，如果出现读写错误、存储的严重警告或突然断开，那么比起调整服务，更应优先备份重要数据。关于 Windows 的存储警告，Microsoft 同样是先引导用户备份。而且没看到警告，并不等于所有磁盘都被保证正常。¹⁵

备份之后，再确认电脑或存储厂商提供的诊断工具，以及适合该机型的驱动程序与固件信息。不要把旧文章里那种成批修改注册表的做法，在没核对机型和适用条件的情况下就拿来先试。例如 Microsoft 关于 SysMain 的已知问题中，也有仅限于 Windows 7 特定条件的内容。仅凭资料的更新日期，无法判断它能适用于现在的 Windows 11。¹⁶

flowchart TB
    accTitle: 出现存储警告时的优先顺序
    accDescr: 出现严重警告或读写错误时，优先备份并做符合机型的诊断，而不是优化设置。
    A["警告或读写错误"] --> B["备份重要数据"]
    B --> C["确认厂商的诊断"]
    C --> D["看适用条件再修理或处理"]

图 12: 出现故障征兆时，保住数据比把百分比降下来更优先。

9. “修好了”不看百分比，要用原来的作业来判定

对策成功与否，要用最初困扰你的那个操作来确认。把“打开应用不再等待”“复制能正常完成”“打字不再卡顿”这些结果和更改前对比。就算磁盘 100% 的时间变短了，如果搜索结果不再更新、保护一直停着，也不算完成。

比较时要统一同样的操作、同样的保存位置，以及尽量相同的后台状态。像 SysMain 那样的临时比较，按“原有状态→停止期间→原有状态”的顺序确认，更容易察觉“只是因为时间过去了工作才做完”的可能。不过第二次会有缓存生效之类的差别，所以不要把一次比较当成证明了因果关系。

这是本文提出的调查思路。与其收集一堆能把数字压下去的设置，不如记录哪一项更改在保住必要功能的前提下改善了原来的操作，这在问题复发时也更有用。

flowchart TB
    accTitle: 对策完成的判断
    accDescr: 除了原来的操作有所改善，还要确认搜索、保护与服务的状态，才算对策完成。
    A["重新执行原来的操作"] --> B["等待时间是否改善"]
    B --> C["搜索与保护是否保住"]
    C --> D["临时更改是否已还原"]
    D --> E["记录条件与结果后完成"]

图 13: 判定依据不是磁盘的数字，而是必要的作业与功能是否一并恢复。

总结

面对磁盘 100%，并不存在把 SysMain、Windows Search、Defender 一起停掉的万能步骤。首先确认时段、目标磁盘、文件和响应时间。在此基础上，SysMain 只在必要时做临时比较，Search 调整搜索范围，Defender 保持保护并做分析——这样的分工是出发点。

如果业务用 Windows 应用持续出现“只有某个操作慢”“只有现场的电脑会卡死”这类问题，也可以通过小村软件的技术咨询来商量。有了发生时刻、重现操作、涉及文件的类型，以及更改前后的记录，调查的切入点就能具体起来。共享日志或记录时，请确认其中不含机密信息。

参考链接

Microsoft Learn, Guidance on configuring system services。关于 SysMain 的职责与禁用服务的注意事项。适用对象是 Windows IoT Enterprise。 ↩ ↩²
Microsoft Support, Search indexing in Windows。关于搜索索引的目的与运作。 ↩ ↩² ↩³
Microsoft Support, Stay protected with the Windows Security app。关于停用实时保护后的影响。 ↩ ↩² ↩³
Microsoft Learn, Troubleshoot performance problems in Windows。关于查看 I/O 响应时间与 System 进程的思路。本文没有把这份面向 Windows Server 的资料中的数值标准，当作所有客户端电脑的合格线。 ↩ ↩²
Microsoft Virtualization Team, Hyper-V Replica debugging: Why are very large log files generated?。用资源监视器把进程与磁盘上的文件关联起来的调查实例。 ↩
Microsoft Learn, Performance analyzer for Microsoft Defender Antivirus。关于扫描的记录与分析步骤。 ↩ ↩² ↩³
Microsoft Learn, Stop-Service。停止服务的命令。 ↩
Microsoft Learn, Start-Service。启动服务的命令。 ↩
Microsoft Learn, about_Try_Catch_Finally。把收尾处理放进 finally 的语法。 ↩
Microsoft Learn, Troubleshoot Windows Search performance。关于搜索范围的调整、重建与进度的查看方式。 ↩ ↩²
Microsoft Support, Windows Search and privacy。关于 Windows Search 的设置与搜索范围。 ↩
Microsoft Learn, Microsoft Defender Antivirus Performance Analyzer reference。关于支持条件、管理员权限、记录与报告命令的规格，以及对排除设置的提醒。 ↩ ↩²
Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows。关于硬页错误与读回来源的说明。 ↩
Microsoft Learn, Introduction to the page file。关于页面文件与提交上限的关系。 ↩
Microsoft Support, What to do about a critical warning for a storage device。关于出现严重警告时的备份指引。 ↩
Microsoft Learn, Superfetch Sysmain service causes CPU usage spikes。这是以 Windows 7 特定条件为对象的已知问题，本文不把它当作 Windows 11 的通用对策。 ↩

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

磁盘使用率都 100% 了，为什么只有几 MB/s？: 因为磁盘处于活动状态的时间，和每秒能传输的字节数是两个不同的指标。细碎的读写和 I/O 的等待时间会让传输量不大却依然很忙。请确认目标磁盘的响应时间，以及缓慢的操作是否同时发生。
禁用 SysMain 一定会变快吗？: 不能说一定会变快。请先保持常规设置，只有在怀疑与 SysMain 有关时，才在记录下原有状态之后比较临时停止与重新启动的差别。是否永久禁用，不要只凭这一次比较来决定。
Windows Search 可以停掉吗？: 它会影响依赖搜索索引的搜索速度和结果的更新，所以不要把它当成第一个对策。先确认索引的进度，如果有不需要的文件夹被纳入了搜索范围，应优先考虑调整这个范围。
可以关掉 Defender 来降低磁盘使用率吗？: 不建议把关闭实时保护当作日常的提速手段。请用 Microsoft Defender Antivirus 的性能分析器记录扫描的负担，查明与哪些文件或处理有关。报告中排在前面的项目，也不能就这样加入排除设置。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

查看简介联系我们

公开链接

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

返回博客列表

磁盘使用率 100% 要停掉什么才能好？──分辨 SysMain、Windows Search 与 Defender

1. 先说结论：不要把三者一视同仁地停掉

2. 100% 既不是“容量已满”，也不是“达到最高速度”

3. 最初的观察：什么时候、哪个文件上变慢

4. 看到了名字，和它就是根本原因，是两回事

5. SysMain：先保持原样，只在有怀疑时做临时比较

面向管理员：把 90 秒比较与恢复合成一段处理

6. Windows Search：停掉之前先想清楚“你想搜什么”

不要把重建当成“先按了再说的修复按钮”

7. Defender：不关掉保护，去查“它在检查什么”

面向管理员：采集记录并查看排在前面的项目

8. 除了这三者也要看：内存与存储的状态

9. “修好了”不看百分比，要用原来的作业来判定

总结

参考链接

同样是 1GB，为什么复制照片文件夹比复制一部视频还慢？

Windows 的“硬件加速 GPU 计划”是什么？打开就会变快吗？

Windows 名称解析的顺序 ── hosts、DNS 缓存、LLMNR/mDNS 与 DoH

关掉内存完整性(HVCI)会变快吗 ── 含义、步骤与判断

WPR/WPA 实务 ── 从系统整体调查「整台 PC 变慢」

相关主题

Windows 技术主题

常见问题

作者简介

Go Komura

1. 先说结论：不要把三者一视同仁地停掉

2. 100% 既不是“容量已满”，也不是“达到最高速度”

3. 最初的观察：什么时候、哪个文件上变慢

4. 看到了名字，和它就是根本原因，是两回事

5. SysMain：先保持原样，只在有怀疑时做临时比较

面向管理员：把 90 秒比较与恢复合成一段处理

6. Windows Search：停掉之前先想清楚“你想搜什么”

不要把重建当成“先按了再说的修复按钮”

7. Defender：不关掉保护，去查“它在检查什么”

面向管理员：采集记录并查看排在前面的项目

8. 除了这三者也要看：内存与存储的状态

9. “修好了”不看百分比，要用原来的作业来判定

总结

参考链接

相关文章

同样是 1GB，为什么复制照片文件夹比复制一部视频还慢？

Windows 的“硬件加速 GPU 计划”是什么？打开就会变快吗？

Windows 名称解析的顺序 ── hosts、DNS 缓存、LLMNR/mDNS 与 DoH

关掉内存完整性(HVCI)会变快吗 ── 含义、步骤与判断

WPR/WPA 实务 ── 从系统整体调查「整台 PC 变慢」

相关主题

Windows 技术主题

常见问题

作者简介

Go Komura