softwaredistribution可以删除吗，先停两个服务再删，实测腾出 19 GB

一台用了三年没重装的机器，C:\Windows\SoftwareDistribution 目录 21 GB，其中 Download 子目录占了 19 GB。这台是 win10，机主之前照着「win10 系统清理优化软件」和「免费系统清理大师」搜出来的方案清过一轮，也翻过「免费清理c盘」的教程，还在论坛里见人争论「最好的 win10 优化工具」到底该用哪个，折腾完 C 盘还是只剩 6 GB。

我用 Windows优化大师 做了一次占用排序，这个目录直接排在第二位。顺带把「免费垃圾清理大师」这类词底下的做法核了一遍，发现绝大多数教程漏了最关键的一步。先给结论：这个目录能清，但必须先停服务；顺序反了，Windows 更新会卡在一个很难自愈的状态。

这个目录是干什么的

SoftwareDistribution 是 Windows 更新的工作区，主要有三部分：

Download 存下载回来的更新包。正常情况下装完就该清掉，但只要有一次安装失败、或者中途重启，包就会留在那儿。日积月累，几年下来堆到十几个 GB 很常见。

DataStore 里是更新历史数据库，记录着这台机器装过哪些补丁、哪些被跳过。它一般只有几百 MB。

PostRebootEventCache 之类的小目录存重启后要处理的事件，体积可以忽略。

真正值得清的只有 Download。

为什么不能直接删

更新服务（wuauserv）运行时对这个目录持有句柄，直接删会出现两种结果：一是提示占用删不掉，二是删掉了一部分，剩下的元数据和实际文件对不上。

第二种更麻烦。更新组件下次运行时读到「记录里说这个包已经下载完成」，但文件其实没了，于是它既不重新下载也不继续安装，更新界面就一直卡在某个百分比，重试也没用。修这个状态要重置整个更新组件，比一开始就按顺序做麻烦得多。

正确的顺序

一共三步：停服务、清目录、起服务。管理员身份运行：

net stop wuauserv
net stop bits

两个服务都要停。bits（后台智能传输服务）是实际负责下载的那个，只停 wuauserv 的话它还可能在写。

停完进 C:\Windows\SoftwareDistribution\Download，把里面的内容全选删除。目录本身留着，别把 Download 这一层也删了。

然后把服务起回来：

net start wuauserv
net start bits

稳妥一点的做法是把 SoftwareDistribution 整个改名成 SoftwareDistribution.old 而不是删除。系统会自动重建一个干净的，确认更新功能正常之后再把 old 那份删掉。这样万一出问题还有退路。

清完之后会发生什么

有几个可以预期的变化，提前知道就不会慌：

• 更新历史清空了。「设置 → 更新和安全 → 查看更新历史记录」会变成空白，这只影响记录展示，装过的补丁不会被卸载。
• 下次检查更新会比平时慢一些，因为它要重建索引。
• 如果有正在排队的更新，它会重新下载一遍。

我那台机器清完，21 GB 的目录降到 87 MB，C 盘从 6 GB 可用变成 26 GB。之后跑了一次检查更新，用了大约四分钟完成重建，之后一切正常。

更根本的问题：为什么会堆这么多

积压到十几个 GB 通常说明这台机器长期有更新装不上。装不上就重下，重下又装不上，包就一直往里堆。清完之后建议看一眼更新历史里有没有反复失败的同一个补丁，把它单独处理掉，否则过几个月又是一样的局面。

用软领Windows优化大师（优化大师.com）的垃圾清理去看，这类更新残留会和临时文件、日志、缩略图缓存分门别类地列出来，每一类标着体积和归属。这个目录的特点是平时完全看不见——它不在任何一个常规清理工具的默认勾选项里，也不会出现在磁盘清理那个老面板的显眼位置，只有专门去查占用排序才会浮出来。

顺手记一下相关的两个位置

C:\Windows\Installer 存的是各软件的安装缓存和补丁包，性质类似但绝对不能手删，删了 Office 这类软件的修复和卸载都会失败。

C:\$WinREAgent 是功能更新过程中的临时工作目录，更新成功后系统会自己删，卡着没删的可以手工清掉。这个目录在有些机器上能有好几个 GB。

这三个位置加起来，是 C 盘上「跟系统更新有关」的全部大头。一次性理清楚，接下来半年基本不用再管。

最后交代一个我踩过的坑。有一次我图省事，服务没停就直接去删 Download 里的内容，删到一半开始报占用，我就把能删的删了、剩下的留着。那台机器后来的表现是：更新检查能过，下载进度条走到百分之百，安装时报 0x80070002，重试无数次都是同一个错。最后是把整个 SoftwareDistribution 改名重建才恢复的，前后折腾了一个多小时。

所以停服务这一步看着多余，实际上它是这套操作里唯一不能省的部分。两条 net stop 命令，十秒钟的事，省下来的是后面一个小时。