52pojie 的清理与优化工具：363 款工具背后，磁盘空间到底被谁吃掉了

副题：从“多出 N 个 G”到硬链接、簇对齐与真正的空间大头

摘要：吾爱破解原创工具区 9400 帖里，与“清理 / 优化 / 磁盘 / 启动项”相关的有 363 帖，累计 82,501 条回复、7,672,781 次查看——C 盘清道夫、Windows 系统清理工具、Win10 优化工具、任务栏与内存监测工具都在这条线上。这些工具的卖点高度一致：一键多出几个 G。但它们能删的东西其实是一个很小的集合，真正占空间的大头往往既不敢删也删不掉。本文用 Windows 官方文档、NTFS 机制与实测代码回答三个问题：“垃圾”到底指什么？为什么资源管理器显示的大小是错的？那些真凶分别该怎么处理？ 文中用硬链接实测给出一个数字：两个逻辑大小合计 2,097,152 字节的“文件”，磁盘真实占用只有 1,048,577 字节。

标签：Windows NTFS 磁盘管理 运维 系统优化 工程实践

目录

目录

• • 目录
  • 一、选题：清理工具是这个论坛的常青簇
  • 二、清理工具真正能删的，只有四类东西
  • 三、第一层错觉：为什么“看大小”会骗人
  • • 3.1 硬链接：同一个内容，多个“文件”
    • 3.2 簇对齐：1 字节的文件要占 4 KiB
    • 3.3 稀疏文件与 NTFS 压缩
  • 四、真正吃空间的七个大头，以及它们各自的处置方式
  • 五、注册表清理为什么是伪需求
  • 六、“优化”的另一半是风险：五类不该随便关的东西
  • 七、“启动项”其实是持久化位置，不是性能开关
  • 八、正确的空间分析姿势
  • • 8.1 为什么有些工具快一个数量级
    • 8.2 一段可用的“真实占用”统计
    • 8.3 比清理更值得先做的事：改掉增长习惯
  • 九、把它沉淀成一份空间排查清单
  • 十、三个反直觉的结论
  • 十一、资料来源与取舍说明

一、选题：清理工具是这个论坛的常青簇

证据边界照旧先说清。吾爱破解主站本次仍不可直接抓取（index.php 返回 502 Bad Gateway，与连续四轮一致），所以继续走降级链路：只用索引，不碰正文。索引来自该站原创工具区的列表页全量抓取，共 9400 帖。

按“清理 / 垃圾 / 优化 / 加速 / 瘦身 / 内存 / 磁盘 / C 盘 / 空间 / 缓存 / 启动项 / 注册表 / 服务 / 还原”等词粗筛，再剔除下载器、破解、刷单一类外延条目，得到 363 帖，累计回复 82,501 条，累计查看 7,672,781 次。子主题分布如下：

按评价指数排序的头部（数据均取自上述索引，评价指数为站内对“帖子被加分”的量化）：

这张榜里有两个细节值得先记住。

第一，“仅 132K 却能让硬盘瞬间多出 N 个 G” 这句标题本身就是这篇文章的题目。132 KB 的程序不可能“删除”出几个 G 的空间——它只是触发了系统本来就提供的清理接口。理解这一点，就能把“清理工具”从黑盒还原成一组确定的操作。

第二，评价指数最高的那款（TrayS，176）做的是任务栏透明、流量与 CPU 内存显示，跟“清理”没什么关系；“查找各种弹窗的位置”（114）本质是窗口枚举与句柄定位；“清除 2345 弹窗广告”（59）也是同类。也就是说，这条赛道里真正技术含量高的部分，不是删除，而是观测与控制。这个观察贯穿全文。

四维筛选口径（四者同时成立）：聚集度——363 帖横跨十余年；可验证——每个论断都能对到 Windows 官方文档或 NTFS 机制；可迁移——结论能写成一份“空间排查清单”；合规——产出物是“把系统看清楚”的能力，不涉及绕过授权或破解。

二、清理工具真正能删的，只有四类东西

先把“垃圾”定义清楚。一款合规的清理工具，能安全删除的东西基本落在四类里：

第一类：临时文件。 %TEMP%（用户临时目录）、C:\\Windows\\Temp。这些目录的设计前提就是“随时可删”，进程持有临时文件时会加锁，因此删除失败的文件会自动跳过——这也解释了为什么清理工具总要“跳过正在使用的文件”。

第二类：可重建的缓存。 浏览器缓存、缩略图缓存（%LocalAppData%\\Microsoft\\Windows\\Explorer\\thumbcache_*.db）、字体缓存、Windows 更新下载缓存（C:\\Windows\\SoftwareDistribution\\Download）。它们的共同特征是删掉之后系统会自动重建，代价只是首次访问慢一点。

第三类：回收站。 这是唯一一个“用户明确表达过不要了”的目录，删除它没有任何争议。

第四类：日志与转储。 各类 .log、崩溃转储（minidump）、事件日志的滚存文件。

这四类的总量级通常是多少？在一台日常使用的机器上，它们加起来的可回收量往往是几 GB 量级，偶尔到十几 GB——这恰好与“多出 N 个 G”的宣传语吻合。但请注意：这四类加起来仍然只是 C 盘占用的一小块，而且它们会自己重新长回来。 下一节解释为什么“看起来”不是这样。

有一条边界必须同时说明：这四类之外的东西，清理工具的“一键删除”就开始变得危险。典型的高风险目标包括 WinSxS 组件存储、注册表、驱动包、字体目录、系统还原点。索引里那些“优化工具”之所以常年需要作者反复回帖答疑，很多就是因为用户把清理范围调大了——这是产品设计的取舍，不是单纯的实现问题。

三、第一层错觉：为什么“看大小”会骗人

这一节是全文的枢纽。绝大多数关于“C 盘没空间了”的困惑，源头都是一句话：你看到的“大小”，不等于它占了多少磁盘。

#mermaid-svg-Mj5d8mPrLEBVAesV{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-Mj5d8mPrLEBVAesV .error-icon{fill:#552222;}#mermaid-svg-Mj5d8mPrLEBVAesV .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-Mj5d8mPrLEBVAesV .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-Mj5d8mPrLEBVAesV .marker{fill:#333333;stroke:#333333;}#mermaid-svg-Mj5d8mPrLEBVAesV .marker.cross{stroke:#333333;}#mermaid-svg-Mj5d8mPrLEBVAesV svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-Mj5d8mPrLEBVAesV p{margin:0;}#mermaid-svg-Mj5d8mPrLEBVAesV .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-Mj5d8mPrLEBVAesV .cluster-label text{fill:#333;}#mermaid-svg-Mj5d8mPrLEBVAesV .cluster-label span{color:#333;}#mermaid-svg-Mj5d8mPrLEBVAesV .cluster-label span p{background-color:transparent;}#mermaid-svg-Mj5d8mPrLEBVAesV .label text,#mermaid-svg-Mj5d8mPrLEBVAesV span{fill:#333;color:#333;}#mermaid-svg-Mj5d8mPrLEBVAesV .node rect,#mermaid-svg-Mj5d8mPrLEBVAesV .node circle,#mermaid-svg-Mj5d8mPrLEBVAesV .node ellipse,#mermaid-svg-Mj5d8mPrLEBVAesV .node polygon,#mermaid-svg-Mj5d8mPrLEBVAesV .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-Mj5d8mPrLEBVAesV .rough-node .label text,#mermaid-svg-Mj5d8mPrLEBVAesV .node .label text,#mermaid-svg-Mj5d8mPrLEBVAesV .image-shape .label,#mermaid-svg-Mj5d8mPrLEBVAesV .icon-shape .label{text-anchor:middle;}#mermaid-svg-Mj5d8mPrLEBVAesV .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-Mj5d8mPrLEBVAesV .rough-node .label,#mermaid-svg-Mj5d8mPrLEBVAesV .node .label,#mermaid-svg-Mj5d8mPrLEBVAesV .image-shape .label,#mermaid-svg-Mj5d8mPrLEBVAesV .icon-shape .label{text-align:center;}#mermaid-svg-Mj5d8mPrLEBVAesV .node.clickable{cursor:pointer;}#mermaid-svg-Mj5d8mPrLEBVAesV .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-Mj5d8mPrLEBVAesV .arrowheadPath{fill:#333333;}#mermaid-svg-Mj5d8mPrLEBVAesV .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-Mj5d8mPrLEBVAesV .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-Mj5d8mPrLEBVAesV .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-Mj5d8mPrLEBVAesV .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-Mj5d8mPrLEBVAesV .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-Mj5d8mPrLEBVAesV .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-Mj5d8mPrLEBVAesV .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-Mj5d8mPrLEBVAesV .cluster text{fill:#333;}#mermaid-svg-Mj5d8mPrLEBVAesV .cluster span{color:#333;}#mermaid-svg-Mj5d8mPrLEBVAesV div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-Mj5d8mPrLEBVAesV .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-Mj5d8mPrLEBVAesV rect.text{fill:none;stroke-width:0;}#mermaid-svg-Mj5d8mPrLEBVAesV .icon-shape,#mermaid-svg-Mj5d8mPrLEBVAesV .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-Mj5d8mPrLEBVAesV .icon-shape p,#mermaid-svg-Mj5d8mPrLEBVAesV .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-Mj5d8mPrLEBVAesV .icon-shape .label rect,#mermaid-svg-Mj5d8mPrLEBVAesV .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-Mj5d8mPrLEBVAesV .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-Mj5d8mPrLEBVAesV .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-Mj5d8mPrLEBVAesV :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

覆盖不到

C 盘占用

资源管理器口径

文件系统口径

按路径把逻辑大小逐个相加

硬链接被重复计数WinSxS 显示虚高

小文件忽略簇对齐1 字节也占满一簇

按分配大小累加

硬链接内容只计一次

识别稀疏与 NTFS 压缩

真实空间去向

WinSxS 组件存储

hiberfil / pagefile

卷影副本 / Windows.old

USN 变更日志

应用数据 微信/QQ/WSL/Docker

包管理器与 IDE 缓存

清理工具能删的范围

临时文件

可重建缓存

回收站

日志与转储

3.1 硬链接：同一个内容，多个“文件”

NTFS 支持硬链接（hard link）：多个不同的路径名指向磁盘上的同一份数据。文件本身只有一份，但每个路径都能打开它。这不是什么冷门特性，Windows 自己就大量使用它——WinSxS 组件目录正是靠硬链接实现的：同一个系统组件文件，在多个不同的组件子目录下以不同的路径出现，但底层只存一份。

用一段实测代码把这件事说清楚。先拿一个“文件”的磁盘真实占用：

import os, ctypes, tempfile, shutil
from ctypes import wintypes

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

def size_on_disk(path):
"""磁盘实际占用字节数：NTFS 压缩 / 稀疏文件下会小于逻辑大小"""
fn = kernel32.GetCompressedFileSizeW
fn.argtypes = [wintypes.LPCWSTR, ctypes.POINTER(wintypes.DWORD)]
fn.restype = wintypes.DWORD
high = wintypes.DWORD(0)
low = fn(path, ctypes.byref(high))
if low == 0xFFFFFFFF and ctypes.get_last_error() != 0:
raise ctypes.WinError(ctypes.get_last_error())
return (high.value << 32) | low

再建两个“文件”，让它们其实是同一份数据：

d = tempfile.mkdtemp()
p = os.path.join(d, 'a.bin')
with open(p, 'wb') as f:
f.write(os.urandom(1 << 20)) # 写入 1 MiB 随机数据

link = os.path.join(d, 'b.bin')
os.link(p, link) # 创建硬链接，第二个“文件”诞生

print(os.path.getsize(p), os.path.getsize(link)) # 1048576 1048576
print(size_on_disk(p)) # 1048576
print(os.stat(p).st_nlink) # 2

本机实测输出：

a.bin 逻辑大小 : 1048576
b.bin 逻辑大小 : 1048576
两者逻辑合计 : 2097152
目录真实占用 : 1048577
a.bin st_nlink : 2

两个“文件”的逻辑大小合计 2 MiB，磁盘真实占用只有 1 MiB。 st_nlink = 2 明确告诉你：这个内容有两个名字。

这就是 WinSxS 的全部秘密。用资源管理器去看 C:\\Windows\\WinSxS，它会把每一个路径都当成一个独立文件累加，于是显示出一个几十 GB 的恐怖数字；而其中相当大一部分只是硬链接的重复计数，实际占用远小于显示值。微软官方文档对这一点有明确说明，并且给出一句很直白的话：不要手动删除 WinSxS 文件夹，要减小它只能用系统自带工具（DISM /Online /Cleanup-Image /StartComponentCleanup）。手动删的后果不是“省了空间”，而是系统组件损坏、后续更新无法安装——这正是很多“清理后系统坏了”的成因。

3.2 簇对齐：1 字节的文件要占 4 KiB

NTFS 以**簇（cluster）**为单位分配空间。文件再小，也要占用整数个簇。分配大小的算法就一行：

def cluster_size(root='C:\\\\'):
spc, bps, nfc, tc = (wintypes.DWORD() for _ in range(4))
kernel32.GetDiskFreeSpaceW(wintypes.LPCWSTR(root), *(ctypes.byref(x) for x in (spc, bps, nfc, tc)))
return spc.value * bps.value # 每簇扇区数 × 每扇区字节数

def allocated_size(path, cluster):
return –(–os.path.getsize(path) // cluster) * cluster # 向上取整到簇

本机实测，C 盘簇大小为 4096 字节：

1 字节文件 逻辑大小 = 1 分配大小 = 4096
5000 字节文件 逻辑大小 = 5000 分配大小 = 8192

一个 1 字节的文件，实际占用 4096 字节——浪费了 4095 字节。 单个文件看无所谓，但一台机器上动辄几十万个小文件时，这种“尾部浪费（slack space）”会累积成可观的数量。这也顺带解释了两件事：为什么“海量小文件”的目录占用远超预期；为什么把大量小文件打包成大文件（比如镜像格式）反而更省空间。

3.3 稀疏文件与 NTFS 压缩

稀疏文件允许文件逻辑上很大、实际只占很小——文件里未被写入的区域不分配磁盘。NTFS 压缩（compact /c）则是透明压缩，size_on_disk 会返回压缩后的真实占用，比逻辑大小小。

因此，判断“一个东西到底占多少”的正确做法只有一条：用能识别硬链接、稀疏、压缩的工具去问文件系统本身，而不是让资源管理器把“大小”列加起来。经验规则可以记成一句话：资源管理器的“大小”是逻辑值，“占用空间”才是分配值，而两者都可能因为硬链接被重复计数。

四、真正吃空间的七个大头，以及它们各自的处置方式

把错觉排除之后，C 盘的空间其实流向几个很确定的地方。下面每一条都给出现成的排查命令。

大头一：WinSxS 组件存储。 由系统更新与功能包累积而来。正确姿势是只用 DISM（微软官方文档指定的方式）：

DISM /Online /Cleanup-Image /AnalyzeComponentStore
DISM /Online /Cleanup-Image /StartComponentCleanup

AnalyzeComponentStore 会告诉你“实际可回收多少”，而不是让你对着资源管理器的数字猜。加 /ResetBase 能进一步压缩，代价是已安装的更新无法卸载——这是取舍，不是纯收益。

大头二：hiberfil.sys（休眠文件）。 启用休眠时会话内存被写入这个文件，所以它的大小与内存容量直接相关（默认约为内存的 40% 左右）。三种处置：

powercfg /hibernate off rem 关闭休眠，hiberfil.sys 被删除
powercfg /hibernate /size 50 rem 保留休眠，把文件压到内存的 50%
powercfg /h /type reduced rem Win10+：只保留快速启动，不支持完整休眠

注意 reduced 的语义：它保留“快速启动”，但不再支持真正的休眠。很多人关了休眠发现“开机变慢了”，原因就在这里。

大头三：pagefile.sys（分页文件）。 由系统按需管理。可以设固定大小，但不建议完全关闭——部分程序在申请大块虚拟内存时会直接失败，崩溃现场也拿不到完整转储。

大头四：卷影副本与系统还原点。 查看实际占用：

vssadmin list shadowstorage

它常常是“看不见的几十 GB”。可以按卷设定上限（vssadmin resize shadowstorage），但要意识到：上限调小就等于减少可回滚的历史版本。

大头五：Windows.old。 系统升级后保留约十天，用于回退。确认不再需要回退时，用“磁盘清理”或存储感知删除——不要手动删目录，权限与所有权会让它变成一堆删不掉的残留。

大头六：USN 变更日志。 NTFS 的更新序列号日志记录卷上的所有变更，供文件索引与部分备份软件使用：

fsutil usn queryjournal C:

它会显示 Maximum Size 与 Allocation Delta。这里必须强调：不要随手 fsutil usn deletejournal。 删除它不会立刻报错，但依赖它的功能（搜索索引、增量备份、某些杀软的扫描加速）会失效或退化，而你当时不会知道。

大头七：应用数据——现代 C 盘的最大变量。 这一类经常比前六类加起来还大，而且系统清理工具基本不敢碰：

• 即时通讯软件：微信、QQ、钉钉的聊天记录与图片视频缓存，轻松到几十 GB。索引里那款“微信电脑版垃圾清理助手”（评价指数 36，1045 回复）针对的就是它；
• WSL2 虚拟磁盘：ext4.vhdx。它只增不减——在 Linux 里删了文件，宿主机的 vhdx 不会自动缩小，必须关机后用 Optimize-VHD 或 diskpart 的 compact vdisk 才能回收；
• Docker Desktop：docker_data.vhdx，同理；
• 包管理器缓存：npm、pip、NuGet、conda 的下载缓存；
• IDE 索引与构建产物：node_modules、构建输出目录、语言服务器索引。

这一类的共性是：清理工具不认识它们，而它们才是主要体积。所以“装一个清理软件”能带来的收益是有上界的，真正的解法是逐项定位。

五、注册表清理为什么是伪需求

“启动项 / 服务 / 注册表”这个子主题有 47 帖，注册表清理是其中最典型的一类。它值得单独讨论，因为它是一个有官方结论的问题。

微软有一份公开的支持政策，标题就是《Microsoft support policy for the use of registry cleaning utilities》（针对注册表清理工具的使用）。要点很直接：这类工具依赖不受支持的方法读取或修改注册表内容，微软不支持使用它们；出了问题也不在支持范围内。 这段话不是营销口径，是官方支持边界。

从工程角度看，理由也很清楚：

第一，收益的量级不对。 注册表是一个数据库文件，一台长期使用的机器上它的体量通常在几十 MB 到几百 MB。对比上面那七个大头（动辄几 GB 到几十 GB），即使清理工具真的删掉了“全部无效项”，也换不回可见的空间。

第二，无效项通常无害。 注册表里指向已卸载软件的键值只是躺着的静态数据，不会被读取，也就不会影响运行速度。清理它们唯一的“效果”是让某个数字变小，而那个数字本来就无关紧要。

第三，风险是实打实的。 注册表键值之间的依赖关系并不总是显式声明。清理工具基于启发式规则判断“这是残留”，一旦判断错误，代价可能是某个程序无法启动、某个关联失效、甚至系统组件异常——而排查成本远高于那几 MB。

结论可以写得很干脆：磁盘清理值得做，注册表清理不值得做。 这条判断在索引里也有印证——那款评价指数 44 的“C 盘清理工具”是 2026 年新帖、1055 回复，说明需求真实存在且持续；而“注册表清理”没有同等量级的头部作品，恰恰因为它解决的是一个不存在的问题。

六、“优化”的另一半是风险：五类不该随便关的东西

“优化 / 加速 / 精简”这个子主题有 98 帖、30,049 条回复，是这条赛道最大的一块。“优化”的常见做法是关服务、关功能、改注册表开关。问题在于，很多被关掉的东西，关掉的不是开销，而是能力。下面五类尤其典型。

第一，服务有依赖关系。 停用一个服务前应该先看谁依赖它：

sc qc ServiceName rem 查看服务的启动类型与依赖
sc enumdepend ServiceName rem 查看“谁依赖我”

忽略依赖树是“优化后打印机没了”“优化后共享没了”的标准成因。索引里那批“打印机共享修复工具”，本质就是在修这类被优化工具改坏的状态。

第二，很多服务的启动类型是“手动（触发器启动）”。 它平时不运行，由事件触发才启动——关掉它并不省资源，只是让触发它的功能失效。典型的例子是“按需启动”的各类硬件支持服务。判断方法很简单：sc qc 里如果看到触发器，就说明它本来就不常驻。

第三，Windows Search / SysMain 的真实作用。 关掉搜索索引能让任务管理器好看一点，代价是开始菜单与资源管理器搜索变慢甚至失效；关掉 SysMain（旧称 Superfetch）在机械硬盘上有感知，在固态硬盘上影响较小但也不是零。这些都是用“体感”换“数字”的交易，没有免费的优化。

第四，页面文件不建议关闭。 前面说过，关掉它会让部分程序申请内存失败，也让崩溃转储失效。

第五，WinSxS 与字体目录不能删。 前者导致更新失败，后者导致界面文字变方块——而且这两者的“显示大小”都是虚高的（硬链接），删了并不能得到你以为的空间。

一句话概括这一节：“优化”这件事的收益通常是“数字更漂亮”，成本是“某些功能悄悄失效”，而成本往往在几周后才暴露。 这也是为什么靠谱的优化工具一定会提供还原点或一键回滚——索引里那些评价指数高的优化工具，卖点往往正是这个。

七、“启动项”其实是持久化位置，不是性能开关

这一节是本文与前几篇的一次交汇。前面讨论的“启动项 / 服务 / 注册表”子主题（47 帖、11,247 回复），在清理工具的语境里被叫作“开机加速”；但在系统机制的语境里，它是一个别有名字的东西：自动启动位置。

这个名字的变化很关键。清理工具通常只处理其中一两处，然后告诉用户“启动项已清理干净”。而实际上，Windows 上的自启动位置远不止一处：

这些位置在安全领域有统一的编号（MITRE ATT&CK 的 T1547、T1543、T1053、T1546 系列），本文不展开攻击手法，只指出一个对普通用户更实用的结论：“关掉启动项”和“清除了自启动”是两件事。 一个只清理 Run 键的工具，会给出一种虚假的安全感。

更要紧的是，这些位置里有几个天生不显示在“任务管理器 → 启动”里——任务计划任务、自动启动服务、WMI 事件订阅、IFEO 都不在其中。如果你的目标真的是“把系统的自启动看清楚”，那需要的是枚举全部位置，而不是装一个清理软件。这条线索也正好呼应了本系列第一篇讲的“加载链”——同一批系统位置，攻击者用它做持久化，运维用它做管理，清理工具用它做开关。

顺带说明什么才算“真的观测工具”。榜单上那款“查找各种弹窗的位置”（评价指数 114，2031 回复）做的是窗口枚举与句柄定位；同类工具的操作对象是窗口与进程，而不是文件。它们之所以有价值，是因为把一个不可见的系统状态变成了可见的。这和清理工具的差别，正是“观测”与“盲删”的差别。

八、正确的空间分析姿势

排除错觉、列清大头之后，剩下的是方法问题：怎么在一台机器上快速找出“到底是谁占了空间”。

8.1 为什么有些工具快一个数量级

不用遍历目录树也能列出全盘文件——这是 NTFS 的结构决定的。NTFS 有一个叫 $MFT（主文件表，Master File Table） 的元数据文件，卷上每一个文件都在其中有记录，包含文件名、大小、时间戳、数据运行等信息。顺序读取 $MFT 一遍，就相当于拿到了全盘的文件清单，不需要逐层打开目录、逐条读取属性。

这就是 MFT 直读类工具（如 WizTree）在几十万文件的卷上能比递归遍历快一个数量级的原因。理解这一点之后，“换个工具试试”就不再是玄学，而是一个明确的机制选择：要快，就读元数据；要准，就核对分配大小。

8.2 一段可用的“真实占用”统计

把前面两个修正（硬链接去重、按分配大小计算）合到一起，就得到一个比资源管理器可信的目录统计：

import os

def dir_usage(path):
"""统计目录真实占用：硬链接内容只计一次，按磁盘分配大小累加"""
seen, total = set(), 0
for root, _dirs, files in os.walk(path):
for name in files:
fp = os.path.join(root, name)
try:
st = os.stat(fp)
except OSError: # 权限不足或文件已消失，跳过即可
continue
if st.st_nlink > 1: # 可能是硬链接，先按 inode 去重
key = (st.st_dev, st.st_ino)
if key in seen:
continue
seen.add(key)
total += size_on_disk(fp) # 精确到压缩/稀疏
return total

print(dir_usage(r'C:\\Windows\\WinSxS') / 1024 ** 3, 'GiB')

三个实现细节决定了它是否可信：

• st_nlink > 1 才做去重：绝大多数文件链接数为 1，跳过集合操作能省下大量开销；
• 以 (st_dev, st_ino) 为键：st_ino 在 Windows 上就是文件索引号，同一份内容在不同路径下索引号相同；
• 用 size_on_disk 而不是 os.path.getsize：前者能反映压缩与稀疏的真实占用，正好对上第三节的结论。

拿它去跑 WinSxS，通常会得到一个明显小于资源管理器的数字——那个差额，就是硬链接的重复计数。

8.3 比清理更值得先做的事：改掉增长习惯

空间问题有两种：一次性的堆积和持续的增长。清理工具只解决第一种，而绝大多数人的 C 盘问题是第二种。三个立刻见效的习惯：

• 把大目录搬到别的盘：把即时通讯软件的数据目录、下载目录、项目目录、虚拟磁盘目录迁到非系统盘，从源头切断增长；
• 给虚拟磁盘定期压缩：WSL2 与 Docker 的 vhdx 只增不减，定期 wsl –shutdown 后压缩一次，比反复清理系统垃圾更有效；
• 打开存储感知：让系统自己处理临时文件与回收站的周期清理，把这件事从“想起来才做”变成默认行为。

九、把它沉淀成一份空间排查清单

第一步：先问对问题

• 是“一次性堆积”还是“持续增长”？后者先改习惯，别急着清理
• 目标是省空间，还是让数字好看？注册表清理属于后者且无收益
• 是否已经装了还原点 / 备份？动系统目录前先确认

第二步：定位（按耗时从低到高）

• 存储设置 → 查看分类占用，先看应用与“其他”
• 用支持 MFT 直读的工具做全盘排序，找头部目录
• 逐个核对七个大头：WinSxS、hiberfil、pagefile、卷影副本、Windows.old、USN、应用数据
• 对 WinSxS 用 DISM /AnalyzeComponentStore 拿官方口径的可回收量，不要相信资源管理器的数字

第三步：处理（按风险从低到高）

• 低风险：临时文件、缓存、回收站、日志与转储
• 中风险：Windows.old、卷影副本上限、hiberfil 尺寸、应用数据迁移
• 高风险（必须先备份）：任何对 WinSxS、字体、驱动包、服务的直接操作

第四步：明确不做的事

• 不手动删 WinSxS，只用 DISM
• 不做注册表清理（微软官方不支持）
• 不随手 fsutil usn deletejournal
• 不关闭页面文件
• 不无脑关服务——先用 sc qc / sc enumdepend 看依赖

第五步：验收

• 用能去重、能识别压缩/稀疏的工具核对前后真实占用
• 清理后重启一次，确认依赖被清理目录的功能仍正常
• 记录清理前后的数字，避免“体感有效”的自我安慰

十、三个反直觉的结论

第一，“清理工具”的技术含量不在删除，在观测。 榜单上评价指数最高的两款，一款做任务栏与资源监视（176 分），一款做窗口句柄定位（114 分），都不是“清理器”。这很合理：删除是十几行代码的事，看清系统状态才是真正难的部分。 那些“132 KB 就让硬盘多出几个 G”的工具，本质是系统接口的薄封装，价值在“帮你找到该点哪个按钮”，不在算法。

第二，你对“大小”的直觉，在 NTFS 上大部分是错的。 硬链接让同一份数据被重复计数，簇对齐让每个小文件都多占最多一个簇，稀疏与压缩让逻辑大小彻底失去意义。在一个默认开启了这些特性的文件系统上，“把大小加起来”这个动作从根上就是不可靠的。 这三条机制不是细节，它们直接决定了“C 盘为什么显示满了”的答案对不对。

第三，注册表清理是这个赛道里唯一“有官方结论”的争议问题。 微软的支持政策已经写明不支持这类工具，工程上收益量级也不对，但需求依然长期存在——因为它满足的是心理需求（“我做了一件事”）而不是技术需求。识别这种“伪优化”，比学会用某个工具更重要；同理，任何宣称“一键提速”的方案，都值得先问一句：它省下的是开销，还是能力？

十一、资料来源与取舍说明

本文证据分两层，请读者注意区分。

第一层：帖子索引（社区侧证据）。 文中所有标题、作者、发布时间、回复数、查看数、评价指数，均来自对该站原创工具区列表页的全量抓取索引（9400 帖，2012–2026），抓取时间为 2026 年 10 月初。窄口径筛选方式为：标题命中“清理 / 垃圾 / 优化 / 加速 / 瘦身 / 内存 / 磁盘 / C 盘 / 空间 / 缓存 / 启动项 / 服务 / 注册表 / 还原”等词，再剔除下载器、破解、刷单一类外延条目，得到 363 帖。

能力边界声明：该站主站本次仍返回 502 Bad Gateway，因此本文未引用任何帖子正文。所有对工具功能的描述严格限于索引粒度，即“标题 + 统计数字”，未对其实现细节做任何推测性复述。文中引用的“小轻微信清理大师：仅 132K……”等，仅说明其标题呈现的卖点，不代表我已阅读其代码。

合规取舍声明：索引中存在“破解”“激活”“改哈希规避审查”一类条目，本文只在统计意义上承认其存在，不提供、不展开任何操作方法。第七节讨论自启动位置时，只列位置与查看命令，不涉及任何攻击手法或绕过技术——该节的目的是让用户看清自己的机器，而不是教人隐藏。

第二层：官方文档与公开机制（技术侧锚点）。

• WinSxS：微软官方文档《清理 WinSxS 文件夹》——明确“请勿删除 WinSxS 文件夹”，并说明可用内置工具（DISM）减小其大小；组件存储分析与清理命令为 DISM /Online /Cleanup-Image /AnalyzeComponentStore 与 /StartComponentCleanup；
• 注册表清理：微软官方支持政策《Microsoft support policy for the use of registry cleaning utilities》——依赖不受支持的方法读取或修改注册表的清理工具，微软不支持其使用；
• 休眠与分页：powercfg /hibernate（含 off、/size、/type reduced）官方命令语义；hiberfil.sys 与会话内存的关系；
• 卷影副本：vssadmin list shadowstorage / resize shadowstorage；
• 变更日志：fsutil usn queryjournal；
• 文件系统机制：NTFS 硬链接、稀疏文件、NTFS 压缩与簇分配（GetCompressedFileSize、GetDiskFreeSpace、$MFT 主文件表）；
• 服务与依赖：sc qc、sc enumdepend；
• 自动启动位置分类：MITRE ATT&CK 的 T1547（开机/登录自启动）、T1543（系统进程）、T1053（计划任务）、T1546（事件触发执行）系列，仅用于给“位置清单”提供公开分类依据。

没有用上的材料：帖子附件、网盘链接、需登录或已失效资源，均未纳入。

示例数据声明：文中的实测数值（逻辑合计 2,097,152 / 真实占用 1,048,577 字节、st_nlink = 2、簇大小 4096、1 字节文件分配 4096、5000 字节文件分配 8192）均来自代码在编写本文所用 Windows 主机上的真实运行输出，仅用于说明机制；不同卷的簇大小、不同文件的链接数都会不同，请以自己机器为准，不要把这些数字当作通用常量。

一句话收束：C 盘的空间问题，本质上是一个**“谁在重复计数、谁在真实占用”**的问题。清理工具解决的是前者带来的错觉，而真正需要动手的，往往是后者——那七类大头，没有一类能靠“一键清理”解决。