C 盘只剩 12 GB，我的自动清理器一晚只抢回 0.29 GB：三条通道的尸检，和一条活口

一、先算收支账：清回来的不够一晚上花的

我给自动化工作台配了一套 C 盘清理系统，每天凌晨跑一轮。最新一轮的结果是这样的：开跑时 C 盘可用 12.08 GB（92.58 GB 的盘，已用 86.9%），收工时 12.11 GB，净增 0.03 GB。

这一轮真实删除了多少？约 0.29 GB：旧日志 0.08 GB、清空回收站 0.20 GB、浏览器缓存 0.02 GB。而同期工作台自己的会话文件和日志还在往盘里写，两天净流失 0.5 GB，七天净流失 5.22 GB。照这个速度，15 到 20 天 C 盘见底。

清理器没坏、脚本跑完了、每一步都有日志。问题在于：它设计上依赖的三条删除通道，两条根本走不通，一条被自己的安全机制截杀。这篇文章就是这场尸检的记录。

二、第一条死路：清理器被安全钩子截杀在半路

主清理脚本的第一层是清系统垃圾：Windows 更新缓存、CBS 日志、DISM 残留。这一层在会话内跑的结果是——所有删除请求全部返回 trash-failed，最后在一个批量删除的中转目录上等一个叫 BULK_GUARD 的状态锁，直到超时，进程直接退出，连清理台账都没来得及写。

这个钩子是运行环境的安全机制，设计意图我能理解：拦住任何批量删除，防止误删。它是 fail-closed 的——不判断你删得对不对，只判断「你在批量删」，然后一律拦下。历史上多次实证：会话内跑主清理，回收量约等于 0。

更麻烦的是这个设计连累了迁移层。我的第二层方案是把大目录迁到其他盘腾空间，迁移的前提是源端能删。但源端删除在会话内必被截杀，「迁移」就变成了「复制」：目标盘多了一份，源盘一字节没少。迁了也白搬，这一层只能整层停用。

教训：判断一个清理链路还能不能用，别看脚本有没有跑完，逐个看每个删除动作的实际回执。fail-closed 的钩子不会报错给你看，它只会让整条链路安静地归零。

三、第二条死路：权限墙挡在计划任务门口

既然会话内跑会被截杀，那就绕开会话，用 Windows 计划任务在夜里独立跑。我把脚本写好了，注册计划任务这一步却过不去：Register-ScheduledTask 返回 0x80070005，拒绝访问——这台机器的运行账号不是管理员。

方案在纸面上是通的，落地第一步就被系统拒了。写好的命令文件只能先存着，等有管理员权限的窗口再注册。这类坑的共性是：报错发生在你方案的第一步，而不是最复杂的部分，很容易让人以为是脚本写错了。其实脚本没错，是权限模型不允许。

四、第三条死路：61,736 个文件的扫描黑洞

做干跑统计时发现，会话历史目录下有 61,736 个文件、约 2.2 GB，大头是百字节级的小指针文件。对这个目录跑一次 find 全量扫描，14 分钟都没扫完——这也解释了为什么守护脚本给清理任务设的 300 秒超时总是被打穿：光「找到要删的东西」这一步就超时了，根本轮不到删。

就算扫描能过，按现在「逐个文件走回收站」的写法，几万次删除操作在数学上就不成立。这种量级的问题必须换批量结构方案，比如按日期整目录删，而不是一个一个文件处理。逐文件思路在小目录上安全，在大目录上就是性能黑洞。

五、唯一的活口，和它抢回来的 200 MB

三条通道里，实测只有一条畅通：PowerShell 的 Clear-RecycleBin。指定盘符清空回收站，这一轮实打实清出约 200 MB（回收站从 234 MB 降到 33 MB），而且不被安全钩子拦截。

加上两个手工兜底——定点删掉日志目录里 8 个超过两天的最大旧日志（79.9 MB，日志目录从 429 MB 降到 353 MB）、删掉 40 个最大的缓存文件（约 15 MB）——凑出了这轮全部的 0.29 GB。

为什么清回收站不被拦？我没法看钩子的内部实现，不下结论，只记录实测事实：这条口子今天能用。这也是整个清理系统目前每天稳定产出的那一环。

六、服务通道也死了，只剩一道选择题

原来的清理服务通道也确认死亡：状态接口和修复接口都返回 HTTP 404，端口已经被别的页面占用。按更早的「工作台永久停用」决定，没有重新拉起。

于是局面变成一道只有三个选项的选择题：给一次管理员权限注册夜间计划任务（脚本已备好，一次能清约 2.5 GB）；或者恢复一个只含修复通道的最小服务；或者什么都不做，接受 15 到 20 天后 C 盘见底。干跑统计显示可清空间其实很充足：63,109 个文件共 2.5 GB，另有待确认的旧工作区 67 个共 3.1 GB——问题从来不是没垃圾，是没有一条能走通的删除通道。

七、三条经验

第一，安全机制的默认姿态决定了链路的上限。 fail-closed 的钩子堵住了误删风险，也堵死了所有批量清理。用这类环境时，先摸清「哪些删除口子是通的」，再设计清理方案，顺序反了就是全套白写。

第二，量级变了，方法必须跟着变。 6 万个文件逐文件删，扫描都扫不完。结构性的膨胀要用结构性的手段：按日期整目录删、整目录迁移，而不是在逐文件思路上打补丁。

第三，清理效果要用净额记账。 只看「删了 0.29 GB」会得出「清理有效」的假结论；同机写入 0.5 GB、净增 0.03 GB 才是真账。任何「回收类」自动化，报表里都应该同时有回收量和同期增量，否则数字再绿也是假绿。