清理磁盘时，最容易让人放松警惕的动作，是把1个看起来可以回收的目录拖进废纸篓。它看上去只是“移动”，好像不会比删除更危险：东西还在废纸篓里，之后反悔也能恢复。
但我最近遇到的1次清理事故，恰好说明了这句话并不总成立。原本只是想处理缓存和过程文件，结果1个位于外置存储上的目录，被移动到了系统盘的废纸篓。系统并没有在同1个卷内改一下目录归属，而是先把内容复制到另1个卷，再尝试删除原位置。大约 9G 的内容因此挤进系统盘，空间从还能工作的状态迅速降到只剩一点点，最后直接报空间不足。
这次让我重新理解了“清理”的含义。表面上我是在找大文件，实际上我是在判断一份数据能不能被重建、有没有正在被使用，以及一次操作会把数据放到哪里。清理动作的风险，不由目录看起来有多大决定，而由路径、卷和恢复方式共同决定。
我最初看到的只是空间告急
当时系统盘可用空间已经降到 4.8G。前1天刚做过1轮清理，空间看起来还比较宽裕，没想到短时间内又明显下降。面对这种变化，最容易做的事情是继续找“大户”，看到缓存目录、临时目录或旧产物，就想着先挪走再说。
我没有立即删除，而是先查增长来源。这个顺序很重要，因为空间减少可能来自持续增长的缓存，也可能来自系统正在写入的中间文件。如果不先找来源，后面会出现1种很危险的错觉：清掉了1个大目录，却没有解决真正的增长点；或者刚清完，后台任务又把空间填回去。
当时的清理审计还遇到另一个限制：无法可靠确认文件是否被进程占用。按照安全规则，无法确认就默认拒绝删除。这会让清理变慢，却避免了把正在写入的素材、渲染中间结果或运行时文件误判为垃圾。在占用状态未知时，暂停自动删除不是效率低，而是把不可逆风险挡在门外。
这一步让我意识到，大文件只是线索，不是结论。它只能回答“哪里占空间”，不能回答“现在能不能动”。
真正的坑藏在路径后面
事故发生在1个缓存目录上。它在表面路径下看起来像普通的本地目录，实际却是指向外置存储的软链接。也就是说，我看到的是1个入口，数据真正所在的位置并不在系统盘。
如果只看目录名称和大小，很容易把它当作系统盘上的缓存；如果只看文件管理器的移动动作，又容易认为移入废纸篓就是把原物放到1个临时回收区。可1旦源目录和目标废纸篓不属于同1个卷，移动就不再是简单的目录改名，而可能退化成“先复制、后删除”。
这次错误捷径就是：看到目录很大，就把它直接移动到默认废纸篓。这个动作在同一卷内通常很自然，但跨卷时会改变成本和风险。约 9G 内容被复制进系统盘的废纸篓后，系统盘只剩下约 116M，复制过程因为没有足够空间而失败。原本想释放空间，反而先消耗了最宝贵的空间。
如果没有及时处理，后果不只是清理失败。系统盘接近写满后，正在运行的程序可能无法写入临时文件，渲染任务可能中断，日志和系统服务也可能出现连锁异常。更麻烦的是，用户可能误以为原目录已经安全移动，继续处理其他文件，直到系统盘彻底失去余量。
先判断数据在哪里，再决定怎么动
发现异常后，我先确认这个缓存目录的真实归属，确认它是外置存储上的软链接，而不是系统盘上的实体目录。这个判断改变了处理方式：不再把它送进系统盘的默认废纸篓，而是把它移到外置存储自己的废纸篓。
我选择这么做，是因为回收区本身也是有卷归属的。把数据留在原卷的回收区，能够避免一次跨卷复制；同时它仍然保留了恢复机会，后续确认无用后再清空即可。处理完成后，系统盘空间恢复到 9.2G，原本占用空间的内容则留在外置存储自己的废纸篓里，没有继续挤占系统盘。
这里有1个容易被忽略的细节：废纸篓不是1个抽象的、全局统1的地方。不同存储卷往往有自己的回收区。跨卷移动时，安全目标不是“默认废纸篓”，而是源数据所在卷的回收区。
这个规则也适用于挂载盘、网络盘和容器卷。名称相同、界面相似，不代表它们共享同一套空间。清理前如果不解析软链接、不确认挂载关系，就无法知道一次看似温和的移动会在哪个卷上产生额外副本。
大小、占用和可重建性要分开判断
处理完跨卷问题后，我又重新看了一遍系统盘上剩下的内容。此时不能因为系统盘仍然紧张，就把所有体积较大的目录都划进清理范围。剪辑素材可能还在使用，运行中的渲染进程可能依赖某些中间文件，版本快照则承担着回退和恢复的作用。它们都可能很大，但“大”不等于“可删除”。
我把判断拆成几层。第1层是路径解析：这个目录是实体目录、软链接，还是挂载点？第2层是卷归属：源和目标是否位于同1个卷？第3层是占用状态：有没有程序正在读取或写入？第4层是年龄和用途：它是刚生成的工作材料，还是长期没有变化的残留？第5层才是可重建性：删除后，能不能通过原始素材、缓存重算或再次下载恢复？
其中最关键的是可重建性。缓存通常可以重建，但“缓存目录”里面未必只有缓存；素材和版本快照可能无法用同样的方式恢复。1个目录名只能提供初步线索，不能替代内容判断。如果占用检查失败，或者数据是否可重建说不清楚，我会把它放进待审，而不是让自动流程替我猜。
这件事让我重新意识到，清理并不是把空间从硬盘里“抠出来”，而是在资源紧张时重新排序风险。可重建的残留优先，正在使用的内容延后，无法确认归属或用途的内容保留。顺序本身就是保护措施。
一套可复用的安全清理流程
以后遇到类似情况，我会把流程固定成 5 步。先查空间变化来源，确认是哪个卷、哪个目录在增长；再解析路径，展开软链接并确认实际位置；然后判断源目录和回收目标是否跨卷；接着检查占用状态、最后修改时间和数据用途；最后根据可重建性决定是直接删除、移到原卷回收区，还是保留待审。
如果源和目标跨卷，就不使用默认移动动作。要么把数据移到源卷自己的废纸篓，要么先确认有足够的目标空间，并明确接受复制成本。对于运行中的素材、渲染进程依赖的文件和版本快照，默认保留；对于占用状态无法确认的目录，默认拒绝自动删除。
我还会给每次清理保留一个简单的结果记录：释放了哪个卷的空间，数据最后去了哪里，是否仍可恢复，哪些目录因为占用或用途不明而跳过。这样做不是为了写一份漂亮的日志，而是为了避免下一次在同一个错误假设上重新开始。
可靠的清理流程，应该先证明“可以动”，再选择“怎么动”，最后才执行“动多少”。
1个流程成熟的标志，不是它能在空间充足时顺利运行1次，而是它在空间已经告急、占用检查不完整、路径又包含软链接时，仍然知道什么时候该停。真正难的不是找到删除按钮，而是给每个动作划出不会伤及正在工作的边界。
下次我会怎么做
下次再遇到磁盘告急，我会先把“查增长来源”放在所有清理动作之前，不因为一个目录很大就直接动它。看到软链接、挂载盘或外置存储时，我会先确认真实卷归属，再决定回收目标；如果需要移动，就优先选择源卷自己的回收区，避免把释放空间变成额外复制。
我会把目录判断固定成几个问题：它是否仍被使用？它是否可以重建？它最近是否仍在变化？它和目标位置是否属于同一个卷？只要其中一个问题没有答案，就不让自动清理直接处理。尤其在占用检查不可用时，宁可暂时少释放一些空间，也不拿正在运行的任务去赌。
这次事故留下的最重要经验，不是记住某个系统的特殊行为，而是记住清理动作背后的判断链。表面上移动和删除只差一个菜单选项，实际却可能涉及复制、卷空间、恢复路径和运行中的依赖。下次我不会先问“这个目录能不能删”，而会先问“它在哪里、谁在用、删掉后能不能重建，以及这一步会把数据放到哪个卷”。