这次我在盘点一批历史分析产物时，先被一个数字吓了一下：总量约 1.1G。直觉会把它理解成一堆可以清掉的旧文件，尤其当目录里同时出现解包目录、反编译结果、原始转储、报告和安装包副本时，按大小排序再删几项，似乎就是最省事的办法。
但继续拆开看，真正属于结论的文件只有约 150MB。剩下的内容虽然也占空间，却不是同一种东西：有些是可以按同一输入重新生成的中间产物，有些是为了分析而复制进来的旧版本输入，还有一些属于工具运行时，正在被其他流程使用。它们的共同点只是“看起来像历史文件”，价值和风险却完全不同。
清理磁盘之前，先要判断文件失去后能不能恢复，而不是先判断它占了多少空间。
这次清理，真正遇到的是什么
当时的问题不是找不到文件，而是文件太多以后，名称和目录结构已经不能直接说明它们的命运。分析工作通常会留下几层东西：最上面是报告、回执和回归基线，代表已经确认过的结论；中间是解包目录、反编译文件和大型原始转储，帮助分析过程继续推进；旁边还可能有为了固定版本而保存的安装包或动态库副本；再往外，是分析工具本身的运行时目录。
如果把这些东西都叫作“缓存”，清理动作就会失去依据。报告删掉，可能丢掉已经验证过的事实；中间产物删掉，通常只是下次重跑；旧版本输入删掉，问题却更隐蔽，因为今天还能从别处找到的版本，升级后未必还能找回。工具运行时如果被误动，影响的也不只是磁盘空间，而是当前正在进行的分析任务。
这件事表面上是空间管理，实际上是在给历史事实分级。我要解决的不是“删多少”，而是“什么可以重新得到，什么必须保住，什么在当前时刻根本不能动”。
先把产物按价值拆开
我最后采用了 4 类，而不是按扩展名或修改时间做一张统一的删除表。
第一类是长期保留。报告和回执属于这一类，回归基线也属于这一类。它们的体积约 150MB，却是已经整理过、验证过、以后可能直接引用的结论。它们不一定是目录里最大的文件，但恢复成本最高，因为重新运行工具不等于重新得到同一份判断。原始过程可以再来，已经确认的事实却不应该因为清理而退回到“等下次重做”。
第二类是可再生产物。解包目录、反编译文件和大型原始转储通常可以通过同一输入重新生成，所以它们适合进入有条件的清理范围。这一类约 621MB，是最可能释放空间的地方。不过“可再生”不等于“随时可删”。如果输入已经不在，或者生成过程依赖某个已经变化的环境，理论上的可再生就不再等于现实中的可恢复。
第三类是输入副本。复制进来的安装包、动态库或其他版本材料，看起来也像临时文件，实际却可能是分析事实的来源。它们约 369MB，按常规空间清理逻辑很容易成为优先目标，但旧版本一旦随应用升级消失，就可能再也补不回来。因此我把它们设为只报告，不自动删除。
第四类是运行时。工具链、工作仓和缓存目录是分析能力本身的一部分。它们不应该被普通的历史产物清理顺手处理，而要单独标成受保护对象。这里的判断重点不是“多久没改”，而是“现在是否仍由任务使用”。
分类的核心不是文件长什么样，而是文件失去以后，结论、输入和生成能力分别会损失什么。
最容易误判的错误捷径
最容易误判的做法，是按文件大小统一删除。大文件往往是原始转储或中间目录，删它们确实可能立刻释放最多空间，于是人会自然地把体积当成风险的反面。但体积只说明占用，不说明替代成本。一个很大的输入副本，可能比一批小报告更难找回；一个很小的回执，可能正是判断某次分析是否完成的唯一证据。
另一个错误捷径是按修改时间删除。旧文件不一定没有价值，新文件也不一定安全。报告可能很久没有更新，却是后续回归时唯一可比的基线；某个输入副本可能刚刚复制进来，但它代表的是已经下架的旧版本。时间可以作为候选条件，却不能单独成为删除理由。
还有一种更隐蔽的误判：既然中间产物可以重建，就把“能重建”理解为“已经有事实源”。如果原始输入没保留、版本已变化，或者生成过程依赖的运行环境被清理，重新执行只能产生另一份结果。它可能看起来很像，却不能证明就是同一事实。
如果不处理这些差异，清理最终会导致两种损失。一种是直接丢结论，下次只能重新解释已经做过的工作；另一种是保留了看似完整的目录，却丢掉了输入副本，等真正需要复核时才发现没有办法重现当时的版本。可重建性必须和事实源、版本和恢复成本一起判断，不能只看生成命令是否存在。
我为什么选择先审计，再清理
这次我没有让清理入口默认直接删除，而是让它先输出盘点结果。审计要回答 4 个问题：文件属于哪一类，来源是什么，重新得到它需要什么条件，当前有没有保护条件。这样做的好处是，清理动作前会留下一个可读的清单，后面即使有人不同意某个分类，也能针对判断本身修正，而不是对着一批已经消失的文件追查。
对于可再生类，我再加上时间条件，例如超过 14 天没有变化，才进入回收候选。这个天数不是价值判断，而是给近期任务留出缓冲。对于输入副本，则只报告不删，把“可能释放空间”和“可能失去旧版本”明确摆在一起。对于长期保留和运行时，则直接标记为受保护，避免清理程序因为大小或时间条件误触。
分析工具运行时，整次清理会被拦截。这是一个看似保守、实际很必要的决定。我选择整体拦截，是因为在进程运行期间，很难只凭目录状态判断某个中间文件是否仍被读取；如果只拦截被发现的单个文件，遗漏一个关联文件就可能让当前任务失败。宁可晚一点清理，也不要为了释放一部分空间破坏正在形成的事实链。
删除动作本身采用可恢复回收，并留下本次清单。这样做不是为了把每次清理都变成复杂审批，而是让误判仍有回头路。真正需要防的不是“永远不删”，而是“没有记录地删掉以后，连自己也说不清删了什么”。
从一次盘点变成可复用方法
我把这次经验压缩成一套可以迁移到其他分析型工具的流程。第一步不是扫文件，而是先列出事实源：哪些材料是外部输入，哪些文件是分析结论，哪些只是为了得到结论而产生的过程数据。第二步给每类材料标注可重建性和恢复成本，至少区分“同一输入可以重做”和“同一版本可能无法补回”。第三步写明保护条件，包括当前运行中的任务、正在使用的工具链和需要长期对照的基线。
完成这 3 步以后，清理策略才有了顺序：长期保留类永不进入自动删除；可再生类经过年龄和状态检查后进入可恢复回收；输入副本只报告，等待明确的人工判断；运行时和活动任务整体保护。每次执行前先审计，执行后保留清单，再用独立检查确认回收范围没有越界。
这里还有一个容易被忽略的延伸：如果中间产物里包含尚未提炼的知识，直接清理仍然可能造成损失。比如函数关系、版本差异和交叉引用还停留在原始转储里，尚未整理成可检索的事实文件，那么它虽然“能重跑”，却不能保证下次能快速得到同样的知识。理想状态不是无限保留所有原料，而是在清理前确认重要事实已经沉淀到可复用的结论层。
一个可靠的清理流程，应该先保护不可替代的事实，再处理可以再生的过程数据，最后才讨论释放多少空间。
下次我会怎么做
下次遇到类似盘点，我会先把“占用多少”暂时放到后面，先问 4 个问题：它是什么来源？它能否按同一版本重建？恢复需要付出什么成本？当前有没有任务或事实依赖它？这 4 个问题没有回答清楚之前，不进入删除阶段。
我还会把结论和原料分开看。报告、回执和回归基线不是因为体积小才保留，而是因为它们承担了判断；安装包副本不是因为体积大才谨慎，而是因为它们可能是唯一的旧版本事实源。中间目录和原始转储可以清理，但前提是输入还在、重要知识已经提炼、运行任务已经结束。
最后，我会坚持让入口默认审计，并把清理结果留下来。一个流程成熟的标志，不是它能一次释放很多空间，而是下一次面对同样混乱的目录时，仍然能说清楚为什么保留、为什么回收、为什么暂时不动。磁盘清理表面上是在减少文件，真正要保住的，却是这些文件背后的恢复能力和判断链。