那次清理电脑，真正让我紧张的不是看到某个目录占了几十 GB，而是系统盘几乎已经没有缓冲空间了。只剩下约 338MB 时，连普通命令都可能因为无法写入临时文件而失败。人在这种时候很容易产生一个冲动：先找最大的目录，能删的马上删，能搬的马上搬，先把红色提示消掉再说。
可是磁盘清理最怕的，恰恰是这种“先动手再判断”。目录大小只能说明它占了多少空间，不能说明里面的文件是不是正在被使用，也不能说明删除后应用是否还能找到它们。磁盘告急时，第一目标不是把最大的目录变小，而是先把系统从危险状态拉回来，再决定哪些数据值得动。
先止血，再开始盘点
当时我先处理的是开发工具产生的可重建缓存，包括几类包管理器和编译过程缓存。这些内容的共同点是：删掉以后，之后需要时还能重新下载或生成；它们虽然会让下一次运行变慢一点，却不会让正在写作的项目失去源文件。
这一步看起来不够“彻底”，但它解决了最急迫的问题。系统盘已经接近写满，如果继续让程序写日志、数据库或临时文件，后果不只是提示空间不足，还可能出现任务中断、应用异常退出，甚至留下没有写完的文件。先腾出一小块可用空间，相当于给后面的检查留出呼吸时间。
我没有顺手删除所有看起来像缓存的目录，是因为“缓存”这个名字并不等于“无条件安全”。有些目录里混着索引、下载中的文件、登录状态或应用自己的数据库。可重建的判断依据不是目录名，而是删除后能否由应用可靠地重新生成，并且不会丢失用户状态。
大目录不等于可以直接处理
有了缓冲空间之后，我才开始看空间到底长在哪里。盘点结果里，应用支持数据、容器数据、各种缓存和家目录中的历史过程数据分别占据了很大比例。它们在文件管理器里可能都只是一个普通文件夹，但处理方式完全不同。
例如，应用缓存可以按白名单处理：只列出已经确认可重建的缓存类型；遇到带有保护含义的名称就停止；如果相关进程仍在运行，也不执行清理。这样做的理由很实际，程序一边写入、一边删除，最容易得到一个表面腾出空间、实际状态已经损坏的目录。
这里最容易误判的错误捷径，就是看到大目录就直接删除或搬走。它忽略了 4 个问题：目录是不是仍在写入，应用是否保存了索引，原位置是否有软链依赖，以及失败后能不能回滚。如果不处理这些问题，清理动作可能从“节省空间”变成“重新安装应用、重新建立索引，甚至找不回工作状态”。
所以我先把内容分成 4 层：可重建缓存、可归档数据、仍在使用的活跃目录，以及高风险个人数据。分类的价值在于，它把“要不要删”改成了几个更容易回答的问题：能不能再生，能不能复制，是否还在变化，丢失后是否无法恢复。
可重建缓存只按规则处理
对第 1 层，我采用的是白名单，而不是黑名单。白名单意味着只处理已经知道用途、确认可以重建的缓存；没有被列入清单的目录，即使看起来很大，也先保留。清理前还要检查应用进程，避免在文件仍被打开时修改它。
这套规则牺牲了一点速度，却减少了猜测。比如，某个下载包可能只是更新残留，也可能正是下一次启动需要的安装材料；某个模型缓存可能很大，但重新下载成本和网络条件未必允许。对它们一概而论，实际上是在把“节省本地空间”的问题，换成“以后能不能恢复”的问题。
我还给这类清理留了一个禁名守护：涉及数据库、索引、登录、配置或正在使用的状态目录时，不因为名称里出现“cache”就放行。清理规则必须先保护不可逆的状态，再追求可回收的空间；宁可少清一点，也不要把可重建和不可重建混在一起。
清理完成后，检查的也不只是剩余容量。还要确认应用能正常启动，项目仍能打开，缓存确实在需要时重新生成。空间数字是结果的一部分，但不是全部结果。
可归档数据要复制、校验，再删除
第 2 层是历史过程数据和已经不在当前工作链路中的旧备份。它们不适合直接删除，因为以后可能还要追溯；但它们也不必继续占据系统盘。对这类数据，我选择归档，而不是清空。
归档的顺序不能倒过来。先在外部位置复制，再核对文件数量、目录数量和字节数，必要时对关键文件抽样校验；确认归档侧能够读到内容之后，才删除原位置。删除后还要保留清单和回滚路径，至少能知道哪些内容被迁移过、迁移到了哪里、验证依据是什么。
当时有一部分迁移任务因为同时存在其他大规模读写而停在只读阶段。这并不代表方案失败，反而说明“现在不能迁移”也是有效结论。多个大任务并行读写，可能拖慢系统，甚至让本来稳定的复制变成难以判断的半完成状态。归档的安全边界不是“复制命令返回成功”，而是复制结果可核对、源文件仍可恢复、当前系统具备独占的读写条件。
如果不这样做，最坏的结果是源文件已经删掉，目标位置却只得到一部分内容；更隐蔽的失败是文件数量看起来差不多，但某些大文件或目录结构已经缺失。只看总容量，无法证明数据真的完整。
活跃目录与高风险数据暂不动
第 3 层是仍在写入的活跃目录，比如当前项目、正在运行的服务和持续增长的工作数据。它们可能占用很多空间，但不能因为“理论上可以搬”就马上搬。迁移过程中如果源目录还在变化，复制出来的版本就可能和实际工作状态不一致；即使保留软链，应用也未必能承受路径变化。
所以我判断，活跃目录暂不迁移是更稳妥的选择。先记录它的增长来源，等任务停止、写入归零、依赖关系清楚之后，再单独安排迁移。对于仍在使用的仓库和数据，保持原位置比多释放一些空间更重要，因为它们承担的是当前生产，而不是历史存档。
第 4 层是高风险个人数据。微信文件就是一个典型例子：存储目录里不只是可以按文件名浏览的媒体，还可能有数据库索引和应用状态。直接在目录里乱删，可能留下“文件还在但应用找不到”，或者“索引还在但文件已经缺失”的不一致。
这类数据的处理原则是使用应用提供的清理、导出或迁移路径；如果没有可靠路径，就把它列为不可触碰项，先不动。容量压力很真实，但它不足以自动授权对个人历史进行不可逆操作。越接近个人记忆、数据库索引和登录状态的数据，越不能用通用的“大目录清理”方法处理。
下次我会怎么做
下次遇到系统盘告急，我会先做只读容量快照，记录总空间、可用空间和主要增长来源；如果只剩几百 MB，就先从白名单里的可重建缓存止血，恢复基本写入能力。接着把候选内容按“可重建、可归档、活跃、不可触碰”分层，而不是按目录大小排序后逐个处理。
对可重建缓存，我会执行白名单、禁名和进程门；对可归档数据，我会复制、核对文件数和字节数，再删除源文件，并留下清单和回滚路径；对活跃目录，我会等写入停止后再评估；对带索引的个人数据，则优先走应用路径，找不到可靠路径就保持不动。
最后，清理不能只看“多出了多少空间”。我还会重新打开相关应用，确认项目、媒体和归档内容都能读取，并对迁移后的文件做一次抽样检查。这样形成的流程，既能解决眼前的空间告急，也不会把未来的恢复成本藏在一次看似成功的删除里。
这件事让我重新意识到，整理磁盘其实是在给数据划边界。真正难的不是找到一个最大的文件夹，而是承认不同数据承担着不同责任：有的可以重建，有的应该保存，有的正在工作，有的即使暂时占空间也不能碰。一个可靠的清理流程，不是删得最多，而是在释放空间的同时，把不可逆的损失挡在流程之外。