type
Post
status
Published
date
Oct 3, 2026
slug
summary
一次大版本升级后清出十个 G 的残渣，以及删之前该问自己的那几个问题。
tags
Write
版本升级
磁盘清理
回滚备份
DSH 排障现场
category
DSH
icon
password
url
那天晚上我以为升级已经结束了。命令跑完，版本号变了，服务起来了，界面能开。我关掉终端去干别的，心里想的是「这事完了」。
第二天早上打开磁盘面板，可用空间比升级前少了将近十个 G。我才意识到，升级这件事真正的工作量，全在它「完成」之后。
这篇写的是那一晚我做了什么，以及更重要的——我凭什么判断某个目录可以删。因为删东西这件事，难的从来不是删，是删之前的那个判断。
一、先别动手，先写清单
我犯过的错是：看到一个大目录，脑子一热就删了，删完才想「刚才那是什么」。
所以这次我改了顺序。第一步不是删，是把所有可疑目录列成一份清单，写清三件事：它是什么、多大、我打算怎么处置。清单写完先提交到版本控制里，然后才动手。
这个顺序看着多余，但它解决一个很实际的问题：清理过程中人是会失忆的。删到第七项的时候，你已经想不起来第三项为什么被判定成安全。有清单在，你随时能回头看当时的理由；万一删错了，也知道该恢复什么。
清单还有个副作用：它会逼你把「我觉得这个没用」变成「我核实过这个没用」。前者是感觉，后者是证据。
二、缓存还是数据，只看一个邻居
清理磁盘最容易踩的坑，是把缓存和数据混为一谈。名字里带 Caches 的不一定都是缓存，名字里带 Application Support 的也不一定都在用。
我后来固定用一个判据：看这个缓存目录旁边，有没有一个同名的、正在被使用的数据目录。
系统里很多应用是这么组织的——缓存放在一个地方，真正的数据放在另一个地方，两个目录名字往往对得上。如果数据目录存在、而且修改时间是当下，那缓存就是缓存，删了应用会自己重建。如果数据目录根本不存在，或者几个月没动过，那这个「缓存」很可能就是它唯一的家，删了就是删数据。
这一条判据帮我避开了三次误删。
第一次是某个开发工具的更新缓存，两个 G 出头。看着很像可以删的东西，但我去找它的数据目录，发现真实数据在另一个位置，一点五 G，完好无损。那这两个 G 确实只是下载下来还没装的安装包，删。
第二次是包管理器的元数据。它的存储目录不在缓存区，缓存区里那份只是索引。删索引不影响已装的包，只是下次装东西要重新拉一遍元数据。
第三次是浏览器。好几个浏览器在缓存区占了大头，但每一个在数据目录那边都有自己的家，书签、登录态、扩展都在那儿。缓存删掉，重开浏览器照常。
判据本身很简单，难的是每次都真的去查一遍，而不是凭目录名猜。
三、同一个安装包的两份拷贝
清理过程中我发现一对很有意思的目录：一个叫更新包，一个叫待安装目录。两个加起来七百多兆。
一开始我以为这是两个不同的东西，差点只删其中一个。后来比对了一下校验值——完全一致。同一个安装包，一份是下载下来的原件，一份是解压或复制过去准备安装的副本。安装完成后，两份都留在了原地。
这类残渣的特征是：它们成对出现，内容相同，而且都不再被引用。 单独看任何一个，你都会觉得「这可能是下次升级要用的」，于是不敢删。只有把两个放在一起看，才能确认它们是同一个东西的两份拷贝。
我后来把这条也加进清单的写法里：如果两个目录大小接近、名字相关，先比一下内容再决定，别分别判断。
四、有些东西必须留下
清理不等于清空。有几样东西我刻意留着，而且留得很明确。
一是回滚备份。升级前那个版本的备份，三百多兆，我留着没动。理由是：新版本跑了一晚上没问题，不代表跑一周没问题。真要回退的时候，重新下载旧版本可能比留着它还麻烦。这份备份的成本是三百兆，收益是「随时能退回去」，很划算。
二是包管理器的缓存。它占的地方不小，删了确实能腾出空间，但它是让升级在二十几秒内装完的原因。删掉它，下次装东西要重新从网络拉几百个包。用一点磁盘换大量的等待时间，这笔账我算得过来。
三是活跃数据。有一个目录的修改时间就是当下，说明它正在被读写。这种目录不管多大都不动。判断活跃很简单：看修改时间，看有没有进程正在用它。
留下来的东西和删掉的东西一样重要。一份只讲「删了什么」的清单是不完整的，它没告诉你边界在哪。
五、日志可以砍，但别砍到零
还有一类东西介于两者之间：日志。
我那个目录里堆了两百多份启动日志，从几个月前一直堆到现在。它们单个都不大，加起来也还好，但数量本身是个问题——真要排查故障的时候，在两百多个文件里找线索是件很痛苦的事。
我的处置是保留最近三份，其余删掉。留三份的理由是：一次故障排查通常只需要看最近几次启动的记录，再往前的基本没有价值。但一份都不留是不行的，出问题的时候你总得有个东西可看。
这里的原则是：日志的价值随时间衰减，但不为零。 所以处置方式不是全删，是留一个窗口。
六、那次升级其实是个伪需求
清理到一半我才发现一件更值得说的事。
我原本的目标是「把桌面端升到最新版」。查了四个地方的口径——应用自身的版本锚点、它独立的更新源、包仓库的版本列表、发布页——四个地方一致指向同一个结论：那个版本还没正式发布，我手上的已经是最新的预发布版。
也就是说，我花了一个晚上清理的残渣，有一部分来自一个根本不存在的升级目标。
顺手还澄清了另一个误解。我一直以为桌面端和网页端共用一份安装，因为它们版本号一样。实际上不是：两份独立安装、独立配置、独立端口，版本号一致只是发布节奏同步。真正共用的是用户目录下的凭证和会话数据。
这两件事都不影响清理本身，但它们说明一个问题：动手之前先确认目标是不是真的存在。 如果我先查清楚「有没有可升的版本」，那一晚的很多工作可以省掉。
可迁移的判据
- 先写清单，再动手。 清单入版本控制，写清每项是什么、多大、怎么处置。清理过程中人会失忆，清单是唯一的记忆。
- 缓存还是数据，看邻居。 判据是相邻的同名数据目录是否存在且活跃，不是目录大小，也不是目录名。
- 成对出现的残渣要一起看。 大小接近、名字相关的两个目录，先比内容再决定，分开判断容易只删一半。
- 留下什么和删掉什么一样重要。 回滚备份、加速用的包缓存、正在读写的数据，这三类明确保留，并在清单里写明理由。
- 日志留窗口，不留全部也不留零。 保留最近几次，够排查就行。
- 动手前确认目标存在。 升级、迁移、替换这类操作，先花五分钟核实「要做的那件事」是不是真的需要做。
那一晚清出来将近十个 G，但我觉得更有价值的不是这个数字，是那份清单。下次再遇到类似的事，我不用重新想一遍。