从 del 到 PowerShell：Windows 系统垃圾清理实战与新方法

在开始讨论各种命令和工具之前，必须先把“系统垃圾”这三个字拆开来看。所谓系统垃圾，并不只是“看起来没用的文件”，而是那些在当下不再参与系统正常运行、可以被安全删除、同时又占据了磁盘空间的内容，包括临时文件、缓存、旧更新残留、日志和各种程序生成的中间文件等。Windows 在长期运行过程中会不断生成这类文件，例如程序安装和升级时的临时拷贝、浏览器和应用的缓存、系统错误时自动生成的转储和报告、Windows Update 下载但已经被替换的补丁包，以及某些应用卸载后留下的配置目录，这些内容如果长期不清理，就会在系统盘中堆积，使 C 盘空间告急，甚至影响系统更新和应用安装。微软官方也清楚这一现实，因此在不同版本的 Windows 中内置了磁盘清理、Storage Sense 乃至 Windows 11 的 Cleanup recommendations 等不同形态的清理工具，用来帮助用户识别并删除这类不再需要的文件。(维基百科)

不过，系统垃圾本身具有一种“模糊边界”的特性，很多文件在当前时刻看似没有用，但并不意味着立刻删除永远不会带来问题。典型例子是历史更新包和旧驱动文件，它们既可以被视作占空间的“旧版本”，也可能在系统回滚或修复时发挥作用。因此在设计任何清理方案时，都不能简单地把所有非当前版本的内容粗暴删除，而是要结合系统版本、使用场景以及是否需要回滚能力来做取舍。对普通桌面用户来说，适度释放 C 盘空间、保持系统可更新重要性更高，而对业务服务器或需要变更审计的环境来说，保留更长时间的更新历史可能更加重要。这也是为什么微软在官方工具中总是提供“扫描并列出可删除类别”，而不是直接全自动清除所有旧内容的原因。(微软支持)

在这种背景下，从命令行的 del，到批处理脚本，再到 PowerShell、DISM 和图形界面的 Storage Sense，它们并不是互相替代的关系，而是不同层次和颗粒度的工具：del 更适合精确地清理特定目录或模式匹配的文件，批处理脚本让这种操作可重复；PowerShell 则引入了面向对象的文件操作和逻辑过滤能力，适合做“按时间”“按大小”“按扩展名”的智能清理；DISM 和组件存储清理偏向于系统内部结构层面的瘦身；而 Storage Sense 与 Cleanup recommendations 则把大量底层能力封装在图形界面和策略里，为普通用户提供更安全的默认选项。(Microsoft Learn)

1.1 系统垃圾的常见类型与误区

从目录层面看，日常最容易产生大量垃圾的区域包括用户临时目录 %TEMP%、系统临时目录 C:\Windows\Temp、浏览器和应用缓存目录、Windows Error Reporting 相关的 ReportQueue 等目录，以及 Windows Update 的下载和缓存目录，这些位置在多篇官方文档和社区讨论中都被反复提及。(Microsoft Learn) 许多用户会简单地把“能删的都删掉”作为目标，在图形界面或文件资源管理器中手工删除这些目录中的所有内容，但往往会遭遇权限不足、文件占用甚至删除后应用异常等问题。事实上，即便是临时目录，也存在一些当前仍在被运行程序使用的文件，这些文件在文件系统层面往往会被共享锁定，如果强行用某些工具“绕过锁定”删除，有时反而会导致正在运行的应用崩溃。因此，正确的做法并不是把临时目录当作一次性“全部清空”的垃圾桶，而是结合“最后写入时间”“文件类型”和“是否为当前会话产生”等条件进行筛选。

另一个常见误区是忽视系统组件存储（WinSxS）和更新缓存，认为它们是不能动的“黑盒”。实际上，在 Windows 10 和 Windows 11 中，组件存储的体积管理已经完全纳入 DISM 和计划任务控制之中，微软提供了 DISM /online /cleanup-image /AnalyzeComponentStore 与 /StartComponentCleanup 等命令以及 StartComponentCleanup 计划任务，用于在保证系统回滚能力的前提下，自动或半自动压缩和清理过期组件。(Microsoft Learn) 如果只是盯着 WinSxS 文件夹的体积，试图通过手工删除子目录来“瘦身”，往往会直接破坏系统更新和服务堆栈的完整性，带来比磁盘占用大得多的隐患。

1.2 清理系统垃圾的安全边界与备份策略

无论采用哪种方法，安全始终是系统垃圾清理的首要前提。对于普通桌面用户来说，最稳妥的方式始终是在图形界面中通过磁盘清理、Storage Sense 或 Cleanup recommendations 这样的官方入口进行操作，因为这些工具会自动过滤掉大多数关键文件类型，并在需要时提示“以前的 Windows 安装”这类潜在影响较大的清理选项。(微软支持) 然而，在实际工作中，尤其是在企业环境或运维场景下，单靠图形工具往往难以满足批量自动化清理的需求，此时 del、PowerShell、DISM 等命令行工具就成为不可或缺的“手术刀”。为了在使用这些工具时守住安全边界，实践中通常会坚持几个原则，例如在执行删除操作前先做“只列出不删除”的模拟扫描，通过日志记录清理的目标列表并留存一段时间，同时在可能的情况下对系统或关键数据进行快照或镜像备份。如果系统已经启用了卷影复制或系统还原点，则应在大规模清理之前手动创建一个还原点，以便在出现问题时回滚。

值得强调的是，很多清理操作都可以被设计成“幂等”的，也就是说，在设定好筛选条件之后，多次执行相同脚本不会对系统产生不断累积的额外影响。例如，使用 PowerShell 按“最后写入时间早于七天”删除临时文件，在第一次执行时会删除大量历史文件，而在后续执行时基本只会处理新产生的陈旧文件，这种设计有助于将清理工作变成一种日常维护动作，而不是需要“鼓起勇气”的一次性大动作。

1.3 Windows 清理工具的发展演变与趋势

从历史上看，Windows 最早提供的磁盘清理工具是图形界面的 Disk Cleanup，即 cleanmgr.exe，它自 Windows 98 时代就已经存在，用来扫描和删除包括临时文件、回收站和旧更新在内的多种系统垃圾。(维基百科) 随着系统功能不断增加，微软在 Windows 10 中引入了 Storage Sense，将部分 Disk Cleanup 能力整合到“设置→系统→存储”界面中，并支持按磁盘空间阈值或时间周期自动清理临时文件和回收站。(Microsoft Learn) 到了 Windows 11，这一功能又被进一步整合到“清理建议”和“存储管理”中，用户可以在一个界面中看到临时文件、回收站、下载、旧 Windows 安装等不同类别的占用情况，并一键执行清理操作。(microsoft.fandom.com)

有趣的是，虽然微软曾在 Windows 10 的文档中提到 Disk Cleanup “将被弃用”，并鼓励用户迁移到 Storage Sense，但在后续版本中，Disk Cleanup 并没有真正从系统中被移除，截至 2024 年，它仍然作为一个可用的系统工具存在，并可通过“清理系统文件”选项访问更深层级的更新残留清理能力。(维基百科) 与此同时，社区也出现了诸如 Cleanmgr+ 这样的第三方工具，试图在保留 Disk Cleanup 配置模型的同时，引入更现代的界面和附加功能，这也从侧面说明“可控、透明”的系统垃圾清理仍然有着广泛需求。(GitHub)

第二章经典命令行清理：del /f /s /q 与批处理脚本实战

在所有清理方法中，最直接也最“古典”的手段就是 del 命令。对于长期使用 Windows 的用户来说，del /f /s /q 这一组合几乎成了“无脑删除”的代名词，但是只有真正理解每个参数的含义，并结合目标路径和通配符谨慎使用，才能在释放空间的同时避免误删。del 的基本语法非常简单：指定一个路径和模式，它就会删除匹配的文件；加上 /S 就会递归子目录；加上 /F 会强制删除只读文件；加上 /Q 会静默执行而不再逐一询问确认。因此，当我们看到类似 del /f /s /q %TEMP%\*.* 这样的命令时，就应该在脑海中自动将其翻译为“在当前用户临时目录中，递归删除所有文件，不提示，不在意只读属性”，这是一种极具威力的操作，需要特别注意路径设置是否正确。

在实践中，如果目标只是清理临时目录、日志目录以及应用缓存所在的特定路径，那么 del 是一种非常高效的工具。例如，当我们确知 C:\Windows\Temp 目录下的大多数内容只是在系统更新和安装过程中产生的中间文件，就可以在管理员命令提示符中使用类似如下的脚本片段进行清理：

@echo off
echo 正在清理系統和用戶臨時目錄...

rem 清理當前用戶 TEMP
del /f /s /q "%TEMP%\*.*"
for /d %%D in ("%TEMP%\*") do rd /s /q "%%D"

rem 清理系統 TEMP
del /f /s /q "C:\Windows\Temp\*.*"
for /d %%D in ("C:\Windows\Temp\*") do rd /s /q "%%D"

echo 清理完成，請重新啟動後觀察磁盤空間變化。
pause

在这个批处理示例中，del 被用来删除文件，而 rd /s /q 则用于删除已经空掉的子目录，从而实现真正意义上的“目录归零”。但出于安全考虑，通常会建议在第一次运行时先去掉 /Q，观察删除列表是否符合预期，或者先把脚本中的 del 替换为 dir，让它仅列出将被删除的文件，用来进行“模拟演练”，当确认无误后再恢复实际删除命令。

2.1 针对日志和错误报告的定向 del 清理

除了通用的临时目录，系统错误报告和日志文件也是磁盘空间的大户。在 Windows 10 和 Windows 11 的官方建议中，使用命令行清理 Windows Error Reporting 的 ReportQueue 目录是一种常见做法，其典型用法之一就是通过 del 的递归强制模式删除该目录下全部日志和报告文件，例如：(TECHCOMMUNITY.MICROSOFT.COM)

@echo off
echo 正在刪除 Windows 錯誤報告隊列文件...

del /q /f /s "%LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue\*"

echo 完成。

这样的命令可以有效清理长期积累的错误报告，并配合系统内置的日志轮转机制，避免相关目录无限膨胀。不过也要注意，有些情况下错误报告对排查系统问题仍有参考价值，因此在企业环境中可以考虑先将特定时间范围内的报告压缩备份到集中存储，再执行删除操作。此外，对安全要求较高的环境而言，错误报告和日志中可能包含路径信息甚至部分数据片段，在删除之前进行集中加密归档，有助于在释放空间的同时保留审计线索。

在批处理脚本中，del 还可以与环境变量和日期比较相结合，构造出更具针对性的清理逻辑。例如，有些管理员会通过 for 循环配合 %%~tF 获取文件的时间戳，再通过外部工具或脚本计算一个“过期日期”，从而实现“只删除 N 天之前的日志文件”这样的策略。尽管这种做法在批处理中略显笨重，但在没有 PowerShell 支持或受限于旧系统环境时，仍然是一个可用的折中方案。

2.2 批处理一键清理脚本的设计要点

把单条 del 命令封装进批处理脚本是许多教程中常见的做法，但要构建真正适合长期使用的一键清理脚本，除了罗列清理目标路径之外，还应在结构设计上考虑可维护性与安全性。一个合理的脚本通常会将“配置”和“逻辑”分离，通过独立的变量区列出所有需要清理的目录、文件模式和保留规则，让使用者在修改清理范围时无需接触底层控制逻辑。同时，可以加入日志输出，将每次执行的时间、目标路径和删除结果记录到一个文本文件中，以便在出现误删或异常时追溯。

例如，我们可以构造这样一个面向桌面系统的批处理脚本，它在顶部定义需要清理的目录变量，然后在下方统一调用一个带有参数的清理子过程：

@echo off
setlocal enabledelayedexpansion

rem 配置區：可按需調整
set CLEAN_PATH_1=%TEMP%
set CLEAN_PATH_2=C:\Windows\Temp
set CLEAN_PATH_3=%LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue
set LOG_FILE=%~dp0cleanup.log

echo [%DATE% %TIME%] 開始清理 >> "%LOG_FILE%"

call :CleanFolder "%CLEAN_PATH_1%"
call :CleanFolder "%CLEAN_PATH_2%"
call :CleanFolder "%CLEAN_PATH_3%"

echo [%DATE% %TIME%] 清理結束 >> "%LOG_FILE%"
echo 完成，詳細請查看 "%LOG_FILE%"
pause
goto :eof

:CleanFolder
set TARGET=%~1
echo 正在清理 %TARGET% ...
echo [%DATE% %TIME%] 清理 %TARGET% >> "%LOG_FILE%"

del /f /s /q "%TARGET%\*.*" >> "%LOG_FILE%" 2>&1
for /d %%D in ("%TARGET%\*") do rd /s /q "%%D" >> "%LOG_FILE%" 2>&1

goto :eof

通过这种方式，我们不仅实现了对多个关键目录的集中清理，也通过日志文件获得了一条“安全绳”。如果某天发现某个目录中的文件被意外删除，只要打开 cleanup.log，就能迅速确认是否是脚本执行导致的，并进一步分析当时的具体删除命令和系统返回信息。

2.3 基于计划任务的半自动 del 清理

当一键清理脚本经过足够时间验证后，就可以考虑把它变成一种常规维护动作，通过 Windows 计划任务定期执行。与完全依赖 Storage Sense 这种图形化配置相比，计划任务触发批处理脚本的方式有更高的可控性，可以精确指定运行时间（例如每周一凌晨两点）、运行账号（管理员或特定服务账号），并在触发条件中加入“空闲时间”或“接通电源时”这样的限制，以减少对用户日常使用的干扰。

在设计计划任务时，一个常被忽略的细节是脚本运行时的“工作目录”。许多管理员习惯将清理脚本放在 C:\Scripts 或类似位置，然后在计划任务中简单填写脚本路径，却忘了设置“起始于”目录，导致脚本中使用的相对路径和日志文件路径出错。因此，建议在脚本内部始终通过 %~dp0 获取脚本所在目录，将日志输出和临时文件都放在同一位置，这样无论脚本从命令行还是计划任务触发，行为都将保持一致。结合合适的触发周期和清理范围，一个基于 del 的半自动清理体系就可以长期稳定运行，为系统提供源源不断的空间“回血”。

第三章基于 PowerShell 的智能清理：从 Remove-Item 到自动化管理

相比传统的批处理和 del 命令，PowerShell 为系统垃圾清理带来了更强的表达能力和更细致的控制粒度。它将文件系统中的文件和目录抽象为对象，可以轻松获取诸如大小、最后写入时间、属性等丰富信息，再通过管道和过滤命令组合成复杂但高度可读的清理逻辑。例如，在一条命令中同时实现“递归遍历某目录、筛选出超过七天未修改的文件、排除指定扩展名、删除并记录日志”这样的任务，这是 PowerShell 的强项，也是现代 Windows 平台上构建清理脚本的主流方式。(Reddit)

一个简单的对比是，将前一章用于清理临时目录的 del 脚本，改写成 PowerShell 版本时可以获得更清晰的结构。以下示例展示了如何使用 Get-ChildItem、Where-Object 和 Remove-Item 组合，实现“清理超过三天的临时文件和空目录”的逻辑：

$paths = @(
    $env:TEMP,
    "C:\Windows\Temp"
)

$threshold = (Get-Date).AddDays(-3)

foreach ($p in $paths) {
    Write-Host "正在清理 $p 中早於 $threshold 的文件..."

    Get-ChildItem -Path $p -Recurse -Force -ErrorAction SilentlyContinue |
        Where-Object {
            -not $_.PSIsContainer -and
            $_.LastWriteTime -lt $threshold
        } |
        Remove-Item -Force -ErrorAction SilentlyContinue
}

foreach ($p in $paths) {
    Get-ChildItem -Path $p -Recurse -Directory -Force -ErrorAction SilentlyContinue |
        Where-Object {
            $_.GetFileSystemInfos().Count -eq 0
        } |
        Remove-Item -Force -ErrorAction SilentlyContinue
}

通过这种方式，我们不仅避免了对“刚刚生成的临时文件”的粗暴删除，还利用 PSIsContainer 属性区分了文件和目录，用单独的逻辑处理空目录，整个脚本在可读性和安全性上都大幅提升。如果需要进一步扩展，比如排除特定扩展名或保留某些工作目录，只需在 Where-Object 中添加条件即可，不必重新设计脚本结构。

3.1 PowerShell 删除命令族与 del 的差异

在 PowerShell 中，最常用的删除命令是 Remove-Item，它本质上是 del 的对象化封装，并通过参数提供了递归删除、强制删除和确认提示控制等功能。例如 Remove-Item -Path $env:TEMP\* -Recurse -Force 与 del /f /s /q "%TEMP%\*.*" 在效果上相近，但前者可以进一步通过 -Filter、-Include、-Exclude、-WhatIf 等参数限制行为。(Hosting Ultraso)

一个常被忽视但非常有用的参数是 -WhatIf，它会让 PowerShell 在执行删除命令时只输出“将要删除什么”，而不真正执行删除，这在调试清理脚本时极其重要。例如：

Get-ChildItem -Path $env:TEMP -Recurse -Force |
    Where-Object { -not $_.PSIsContainer } |
    Remove-Item -Force -WhatIf

运行这段代码时，PowerShell 会逐一列出“将删除”的文件路径，但不会真正修改磁盘内容，从而让你有机会评估筛选条件是否过于激进。待确认无误后，只需去掉 -WhatIf 参数，就能把预览变成实际执行，这是 PowerShell 相比传统 del 在安全性上的一大优势。

3.2 按时间、大小和扩展名的多维度智能清理

在系统垃圾清理领域，最常用的筛选维度包括“时间”“大小”和“类型”。例如，在日志目录中，我们往往希望保留最近 N 天的日志文件、删除更早的内容；在某些下载缓存目录中，我们可能只想删除超过一定体积的大文件；而在临时目录中，我们通常只对特定扩展名（如 .tmp、.log、.bak）的文件感兴趣。传统 del 命令虽然可以通过通配符粗略地按扩展名筛选，但在时间和大小维度上的表达能力非常有限，而 PowerShell 在这方面则得心应手。(SQLServerCentral)

例如，下面的脚本展示了如何删除某个目录中“超过 18 小时未修改的日志文件”，这种模式在许多社区分享的清理方案中被广泛使用：

$path = "D:\Logs"
$threshold = (Get-Date).AddHours(-18)

Get-ChildItem -Path $path -Recurse -Force -ErrorAction SilentlyContinue |
    Where-Object {
        -not $_.PSIsContainer -and
        $_.Extension -in ".log", ".tmp" -and
        $_.LastWriteTime -lt $threshold
    } |
    Remove-Item -Force -ErrorAction SilentlyContinue

通过 Extension 属性，我们可以精准控制删除的文件类型；通过 LastWriteTime 和 AddHours / AddDays 方法，我们可以构建精确到小时甚至分钟的时间窗口；如果再加入 Length -gt 10MB 这样的条件，就可以进一步只删除“大文件”，而保留小体积的文本日志。借助这些维度，清理脚本可以根据业务和应用的具体需求进行定制，而不再是“一刀切”的纯粹腾空间操作。

3.3 利用 PowerShell 实现日志压缩与归档再清理

在一些对审计有要求的环境中，系统垃圾清理并不意味着简单删除，而是“压缩归档后再清理”。PowerShell 在这方面同样提供了丰富的支持，Compress-Archive 可以方便地将旧日志打包成 ZIP 文件，同时大幅压缩空间占用，再通过 Remove-Item 删除原始文件，从而在保留记录的前提下释放大量磁盘空间。例如：

$logPath   = "D:\AppLogs"
$archive   = "D:\Archive\logs_{0:yyyyMMddHHmm}.zip" -f (Get-Date)
$threshold = (Get-Date).AddDays(-7)

$filesToArchive = Get-ChildItem -Path $logPath -Recurse -Force |
    Where-Object {
        -not $_.PSIsContainer -and
        $_.Extension -eq ".log" -and
        $_.LastWriteTime -lt $threshold
    }

if ($filesToArchive.Count -gt 0) {
    $filesToArchive | Compress-Archive -DestinationPath $archive -Update

    $filesToArchive | Remove-Item -Force -ErrorAction SilentlyContinue
}

通过这种模式，系统垃圾清理从单纯的删除升级为“生命周期管理”：日志首先在热存储中保留一段时间，以便随时查看；当超过设定阈值后自动转入压缩归档；再进一步，当归档文件达到一定数量或时限时，可以通过单独的脚本将其移动到冷存储或对象存储中，实现真正“低成本长期保留”。这种多阶段策略，比单次粗暴删除更适合生产环境，也体现了 PowerShell 在现代运维体系中的重要地位。

第四章图形化工具：Disk Cleanup、Storage Sense 与 Cleanup Recommendations

尽管命令行和脚本在灵活性和自动化方面优势明显，但对于大部分终端用户和部分桌面场景来说，图形化工具仍然是最直观、最安全的选择。微软在 Windows 中提供的 Disk Cleanup、Storage Sense 和 Windows 11 的 Cleanup recommendations，就是在“易用性”和“可控性”之间平衡的经典代表。(维基百科)

4.1 Disk Cleanup（cleanmgr.exe）的深度使用

Disk Cleanup 作为一个“老资格”工具，虽然界面朴素，但功能并不过时。通过在开始菜单搜索“磁盘清理”或直接运行 cleanmgr.exe，用户可以选择目标驱动器并扫描其中可删除的文件类别，包括临时文件、回收站、系统错误内存转储、临时 Internet 文件等。更重要的是，通过点击“清理系统文件”，可以进入更深层次的清理视图，看到 Windows Update 清理、旧的 Windows 安装、设备驱动包备份等占用大量空间的项目。(维基百科)

从系统垃圾清理的角度看，Disk Cleanup 的优势在于它对“安全边界”有着较好的内建理解。例如，当你勾选“以前的 Windows 安装”选项时，系统会明确提示这一操作将删除用于回滚到旧版本的文件，操作不可逆。而对于 Windows Update 清理，它会基于当前组件存储状态自动决定可以删除的旧补丁，而无需用户了解 WinSxS 的内部结构。这种高度封装的设计非常适合不熟悉命令行的用户，甚至在许多专业教程中也建议“先用 Disk Cleanup 清理一遍，再考虑 DISM 和脚本等高级方式”。

4.2 Storage Sense 与 Cleanup Recommendations 的自动化策略

在 Windows 10 引入的 Storage Sense 以及 Windows 11 中演进为 Cleanup recommendations 的功能，是微软对磁盘空间管理思路的一次升级。与传统的 Disk Cleanup 不同，Storage Sense 更强调“自动化”和“实时性”，用户可以在设置中配置按天、按周甚至在磁盘空间紧张时自动清理临时文件和回收站内容，并选择是否自动清理下载文件夹中超过一定时间未访问的文件。(Microsoft Learn)

在 Windows 11 中，这一功能进一步被整合到“设置→系统→存储→清理建议”中，系统会主动扫描并分类显示诸如临时文件、回收站、下载、大型或未使用的文件、云内容本地缓存等，并在界面中给出每类可释放空间的估算值，用户可以逐项勾选后执行清理。(microsoft.fandom.com) 对于不擅长使用命令行的用户来说，这种图形化“盘点+确认+执行”的流程既保留了一定的可见性，又避免了复杂的命令细节，非常适合作为日常维护的主力工具。

4.3 图形化工具与命令行清理的互补关系

在实际运维中，图形化工具和命令行清理并不是二选一，而是典型的互补关系。一方面，Disk Cleanup 和 Cleanup recommendations 可以快速帮助我们了解当前系统中哪些类别的文件占用空间最多，为后续的脚本化清理提供参考。例如，当你发现“临时文件”和“错误报告”占用异常大时，就可以考虑在 PowerShell 脚本中重点处理相关目录；另一方面，对于某些必须谨慎操作的系统内部结构（如组件存储），通常建议优先依赖 DISM 和 Disk Cleanup 提供的官方清理路径，而不是编写自定义 del 或 Remove-Item 脚本直接操作 WinSxS 目录。(Microsoft Learn)

从长期策略来看，一个比较健康的做法是：将 Cleanup recommendations 之类的图形工具作为用户日常或每月手动清理的入口；将 PowerShell 和 del 脚本用作管理员层面的定期自动化维护；将 DISM 和组件存储清理视作“按需运行”的深度维护手段，当系统更新频繁或 C 盘空间持续吃紧时再启用。这样的层次划分既可以降低误操作风险，又能充分发挥各类工具的优势。

第五章深度清理：组件存储、更新残留与系统日志

当系统运行时间足够长、累积更新次数足够多时，即使已经定期清理临时文件和回收站，C 盘空间仍可能出现持续吃紧的情况，此时问题往往出在 Windows 的组件存储（WinSxS）和更新缓存上。正如微软官方文档所强调的，WinSxS 目录不仅包含当前版本的系统组件，还保留了用于回滚和修复的旧版本文件，因此它会随更新而增长，但又不能简单通过手工删除来“瘦身”。(Microsoft Learn)

5.1 认识 WinSxS 组件存储的清理边界

WinSxS 目录的体积常常令用户惊讶，但其中相当一部分空间其实是“可回收”的，只是回收动作需要通过 DISM 或计划任务来进行。微软提供的 DISM /online /cleanup-image /AnalyzeComponentStore 命令可以对组件存储进行分析，列出实际占用空间、可回收空间以及是否建议进行清理；而 /StartComponentCleanup 命令则可以删除已经被新版本替代的组件，从而减小 WinSxS 的大小。

一个典型的清理流程如下，这里用管理员 PowerShell 或命令提示符执行：

DISM /online /cleanup-image /AnalyzeComponentStore

DISM /online /cleanup-image /StartComponentCleanup

如果希望在确保系统稳定后进一步删除所有可回滚到旧版本的组件，还可以使用 /ResetBase 参数，但这会彻底移除当前所有已安装更新的回滚路径，因此只适合在经过充分验证、确认不再需要卸载任何更新的场景下使用：

DISM /online /cleanup-image /StartComponentCleanup /ResetBase

在部分文档中，微软还提供了通过计划任务 \Microsoft\Windows\Servicing\StartComponentCleanup 或 schtasks.exe /Run /TN "\Microsoft\Windows\Servicing\StartComponentCleanup" 触发清理的方式，使组件存储瘦身与系统维护任务更紧密结合。(Microsoft Learn)

5.2 Windows Update 缓存与 SoftwareDistribution 目录

除了 WinSxS，Windows Update 的下载缓存也是一个常见却容易被误操作的区域。C:\Windows\SoftwareDistribution\Download 目录中存放着大量更新包的下载文件，当系统遇到更新失败或反复重试时，这个目录可能堆积大量残留内容。许多解决更新问题的官方和社区教程都会建议在停止 Windows Update 服务后清空该目录，从而迫使系统重新下载最新更新。(Ten Forums)

在系统垃圾清理的语境下，如果你已经完成了所有更新并确认系统运行稳定，定期清理 SoftwareDistribution 的 Download 子目录可以释放一定空间。但需要注意的是，直接删除整个 SoftwareDistribution 目录可能会影响更新历史和统计数据，因此更稳妥的做法是仅操作 Download 子目录，并在执行前停止相关服务，例如使用如下批处理脚本片段：

@echo off
net stop wuauserv
net stop bits

rd /s /q C:\Windows\SoftwareDistribution\Download

net start wuauserv
net start bits

这种做法在更新故障排查中尤为常见，既可以解决因下载缓存损坏导致的更新失败，又能在一定程度上释放磁盘空间。不过，由于它改变了系统更新的“缓存状态”，因此更适合作为“有目的的维护手段”，而不是高频率的日常清理动作。

5.3 系统日志和临时文件的集中治理

除了组件存储和更新缓存，系统日志和错误报告也可能在长期运行中逐渐堆积。Windows 本身对事件日志有一定的轮转策略，但应用程序和第三方服务生成的日志往往缺乏统一的管理，因此在设计系统垃圾清理方案时，最好将日志目录纳入一个统一的视图。可以通过 PowerShell 遍历常见的日志路径（如 C:\ProgramData 下的某些子目录、特定服务的 log 文件夹），根据文件扩展名和时间进行统筹清理。(SQLServerCentral)

例如，可以构建一张简单的表格来规划不同类别日志和临时文件的清理策略：

类型	示例路径	典型扩展名	推荐保留时间	建议清理方式
系统事件日志导出	D:\Logs\SystemExport	.evtx	90 天	先压缩后删除原件
应用程序文本日志	D:\AppLogs、C:\ProgramData*\logs	.log、.txt	30–90 天	按时间和大小定期清理
临时调试和跟踪文件	%TEMP%、C:\Windows\Temp	.tmp、.etl 等	7–30 天	递归删除旧文件
错误报告和转储	%LOCALAPPDATA%\Microsoft\Windows\WER、Memory.dmp 等	.dmp、.wer	7–30 天	必要时导出后删除
下载缓存	浏览器缓存、SoftwareDistribution\Download 等	各种	视场景而定	按需清理或通过图形工具处理

通过类似的规划表，可以在团队内部形成一致的清理策略，避免不同管理员各自为政、标准不一的情况，也让系统垃圾清理从“临时救火”变成可持续的运维流程。

第六章新兴工具、综合实践与长期维护策略

随着 Windows 平台不断演进，针对系统垃圾清理的生态也在不断丰富。除了微软自身提供的 Disk Cleanup、Storage Sense 和 Cleanup recommendations 外，社区和第三方开发者也推出了各种工具，试图在保持安全的前提下提供更强大的清理功能和更便捷的界面。其中，有的工具像 Cleanmgr+ 那样在 Disk Cleanup 的基础上进行界面和功能增强，有的则通过 PowerShell 脚本框架或图形前端，把复杂的清理逻辑封装为可配置的模板。(Reddit)

6.1 Cleanmgr+ 等替代方案的角色定位

以 Cleanmgr+ 为例，这是一款试图“延长 Disk Cleanup 使用寿命”的工具，它利用 cleanmgr.exe 的配置接口和脚本能力，在新的界面中呈现磁盘清理项目，同时增加了对某些现代清理需求的支持，例如特定浏览器缓存、应用程序残留等。(GitHub) 对于熟悉 Disk Cleanup 行为、又希望获得更现代体验的技术用户来说，此类工具可以起到承上启下的作用。不过，从安全和可维护性角度而言，在生产环境中仍然应优先考虑微软官方提供的工具和接口，把第三方工具作为辅助手段，而不是完全替代。

在选择此类工具时，应重点关注其是否开源、是否有透明的清理规则说明、是否支持日志记录和恢复选项。对于那些“只提供一个按钮、一键清理所有垃圾”的工具，尤其是带有广告或不明来源的程序，更要保持高度警惕，因为系统垃圾清理需要较高权限，一旦工具行为不透明或存在恶意逻辑，后果可能远比磁盘空间不足严重得多。

6.2 自建轻量清理工具的思路：从脚本到 GUI

对于有一定脚本基础的开发者或运维人员来说，利用 PowerShell 和批处理脚本构建自己的轻量清理工具，往往比依赖复杂的第三方软件更可控。一个常见的做法是将前文介绍的 del 和 PowerShell 清理脚本封装成一个统一入口，例如提供一个主 PowerShell 脚本，内部调用不同模块化函数来处理临时文件、日志、更新缓存和组件存储分析，并通过简单的菜单让用户选择要执行的操作。

进一步的扩展是使用 Windows Presentation Foundation（WPF）或 WinUI 为这些脚本开发一个简单图形界面，让非技术用户也能通过勾选和按钮来触发脚本中的逻辑，而不必关注内部具体的命令。由于 PowerShell 本身就支持加载 XAML 界面，构建这样的“脚本驱动 GUI 工具”并不需要完整的应用开发流程，也便于在团队内部维护和迭代。在设计这类工具时，建议保留“模拟运行”选项，即在执行真正删除之前先以日志或列表形式呈现即将删除的文件，确保用户有机会复核清理范围。

6.3 综合实践案例与长期维护策略

综合前文介绍的各种方法，一个成熟的系统垃圾清理方案，往往并不是依赖单一工具，而是由多层次的实践组合而成。可以想象这样一个长期维护策略：在桌面层面，普通用户每月或每两周通过 Cleanup recommendations 或 Disk Cleanup 手动清理一次临时文件和回收站，同时在浏览器和大型应用中开启自动缓存管理功能；在管理员层面，通过 PowerShell 和 del 脚本，每周或每月对关键目录（如 %TEMP%、C:\Windows\Temp、应用日志）进行按时间阈值的自动清理，并与备份和归档策略结合；当系统运行时间较长、组件存储体积比平时明显膨胀时，再按需运行 DISM /online /cleanup-image /AnalyzeComponentStore 和 /StartComponentCleanup，必要时结合 /ResetBase 进行一次集中瘦身。(Microsoft Learn)

在这一过程中，最重要的并不是某一个具体命令，而是“可见性、可回滚性和可重复性”三大原则：可见性要求在每次清理之前都要有足够的信息展示（无论是 Disk Cleanup 的类别列表，还是 PowerShell 的 -WhatIf 输出）；可回滚性要求在执行高风险清理之前做好系统还原点、镜像备份或日志记录；可重复性则要求清理方案能够通过脚本和配置稳定复用，而不是一次性的“临时操作”。只有将这三点真正落实到实践中，系统垃圾清理才能从“救急措施”升级为日常运维的一部分，让 Windows 在长期运行中保持瘦身、稳定和可控。

最后，无论你偏爱命令行还是图形界面，都可以从最熟悉的工具入手，逐步将 del、PowerShell、Disk Cleanup、Storage Sense、DISM 等方法串联成一套属于自己的清理“工具箱”。当你在管理员命令提示符中敲下 del /f /s /q 的时候，不再只是机械地执行教程中的命令，而是清楚地知道自己在删除什么、为什么删除以及如何在需要时恢复，这才是系统垃圾清理真正的“高级境界”。