WinSxS 文件夹里装着什么——以及它为什么看起来比实际更大
WinSxS 文件夹（Windows Side-by-Side）就是组件存储：它保存着装机以来安装过的每个系统组件的每个版本，外加让更新、功能和维护得以运转的元数据。累积更新替换 System32 里的文件时，旧版本会留在 WinSxS，这样无需原始介质就能卸载更新、修复功能。用了两年的系统上，它轻松长到 6–15 GB。
资源管理器报告的大小同样有误导性。System32 和 WinSxS 里的文件是硬链接——数据只有一份物理拷贝，却在两处都被计入——所以简单相加文件夹大小，会把只存在一次的 GB 数成两遍。这就是为什么 12 GB 的 WinSxS 文件夹并没有从你的磁盘偷走 12 GB，也是为什么任何第三方“WinSxS 清理器”都无法诚实地兑现它显示的那个数字。
- 每次累积更新后被取代的组件版本——膨胀的主因
- 让更新可以卸载的备份——只有 /ResetBase 能移除
- 可选功能的负载（RSAT、.NET 3.5、语言包）——日后安装功能时用得上
- 与 System32 共享的硬链接——一个文件在多个文件夹里被计数
- DISM 分析给出诚实数字：“Actual Size of Component Store”与“Shared with Windows”
安全清理：两条 DISM 命令
以管理员身份打开命令提示符，先跑只读分析：Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore。一两分钟就结束，最后一行是 “Component Store Cleanup Recommended : Yes” 或 “No”，还会给出存储的实际大小和与 Windows 共享的部分。如果是 No，就没油水可捞——关掉窗口继续过日子。
如果建议清理，运行 Dism.exe /Online /Cleanup-Image /StartComponentCleanup。它移除被取代的组件版本，机器照样可更新，但可能要跑 10–30 分钟，期间 DISM 进程看起来像挂住了——让它跑完，因为中断正是那些罕见损坏故事的源头。加上 /ResetBase 会移除所有被取代版本，把存储压得更小，但此后任何已安装的更新都无法卸载——这笔交易只在你从不回滚的稳定机器上才划算。
绝不能做的事——以及如何管住 WinSxS
三件事永远不许做：手动删除或移动 WinSxS 内部的文件（哪怕“只删最大的几个”）、把注册表清理器或“系统优化器”指向这个文件夹、对它启用 NTFS 压缩。每一件都会破坏硬链接或维护元数据，轻则更新装不上，重则系统再也起不来。组件存储只有一条受支持的清理路径：DISM，以及它在磁盘清理中的等价物——“Windows 更新清理”项。
Windows 自己也会搭把手：内置计划任务 \Microsoft\Windows\Servicing\StartComponentCleanup 会在后台自动执行同样的清理，并在组件被取代后先等上大约 30 天再移除。手动跑一轮的价值在于大批累积更新之后，或给机器做镜像之前。至于周边的一切——临时文件、传递优化残留、旧缓存——Kleaner PRO 的计划清理会照看好磁盘其余部分，而 WinSxS 本身仍是 DISM 的地盘。
常见问题与解答
删除 WinSxS 文件夹里的文件安全吗？
不安全。手动删除会破坏硬链接和维护数据——从更新失败到系统无法启动都有可能。唯一受支持的清理是 DISM StartComponentCleanup 或磁盘清理里的“Windows 更新清理”。
Windows 11 里 WinSxS 文件夹多大算正常？
更新了一两年的系统上 6–15 GB 属于正常。明显超过 20 GB 时，运行 DISM 分析——它会告诉你清理到底值不值。
DISM /ResetBase 是干什么的？
移除每个组件所有被取代的版本，把存储压缩到普通 StartComponentCleanup 达不到的程度。代价是：已安装的更新再也无法卸载。
继续阅读
联系我们: [email protected]