那次发现系统盘快要没有空间时，我第一反应也是找出最大的目录。成片、归档、已经完成的批量产物，和应用草稿、会话记录、运行数据、缓存放在了一起。列表里最大的文件夹看起来很有吸引力，仿佛只要把它整个剪切到共享盘，问题就解决了。
但我很快停了下来。这个问题表面上是“哪里占空间”，实际上是“搬走以后，谁还会继续找它”。一批成片可能只是偶尔查阅的冷数据，应用草稿却可能在下一次启动时被程序自动读取。它们都表现为文件，却不是同一种文件。
磁盘清理真正要分的不是大小，而是数据离开原位置以后还承担什么作用。
快满只是表面问题
只读盘点先确认了系统盘确实已经接近耗尽。候选目录里既有可以长期归档的内容，也有正在被工作流使用的内容。这个阶段最容易被“空间焦虑”牵着走：看到一处占用大，就想立刻处理；看到共享盘空间充足，就想把本机上的东西尽量搬过去。
可是空间不足只是一个约束，不是搬迁规则。系统盘继续满下去，可能导致新文件无法写入、导出中断，甚至让应用在保存草稿时失败。如果为了释放空间，反过来把应用需要的数据库、草稿或会话数据移走，后果会更隐蔽：程序可能启动异常，历史记录找不到，或者某个自动流程仍然沿旧路径读取，最后把软链接故障误认为是应用本身的问题。
这件事让我重新意识到，清理磁盘不是一次性的家务，而是在重新安排数据和程序的关系。只看“谁最大”，会把一个依赖关系问题，误处理成简单的删除问题。
我先按使用方式分层
我没有马上剪切目录，而是先建立用途清单。每个候选目录只回答一个问题：它是程序会自动读取的工作数据，还是人偶尔才会查阅的资料？如果两者都不是，再判断它是不是可再生缓存。
第1类是程序仍要自动读取的数据。应用草稿、会话记录、运行数据，哪怕平时看起来只是一些零散文件，也可能参与恢复、索引或下一次启动。它们不能因为体积不大就被忽略，也不能因为占用明显就整批搬走。对这类数据，我判断可以放到本机外置盘，但要保留稳定的访问路径。
第2类是人偶尔查阅的冷数据。成片、归档和已经完成的批量产物，通常不需要每次启动应用时都在本机等待。它们适合迁到高速共享盘，重点从“随时被程序找到”变成“需要时能可靠取回”。
第3类是可再生缓存。缓存的判断不能只看名称，还要看删除以后能不能由系统或应用重新生成。如果再生代价可以接受，缓存就不应该和唯一的工作成果使用同一套保护级别；如果里面混有无法重建的中间结果，也不能因为它叫缓存就直接清空。
分层的依据是访问责任：程序自动读、人偶尔查、或者丢了还能再生。
最容易误判的捷径
错误捷径是按目录大小排序，看到最大的文件夹就直接剪切到共享盘。它的诱惑在于立刻见效，空间数字也可能马上变好。但目录大小只说明“现在占了多少”，并没有说明“谁依赖它”。
还有一种看起来更稳妥的做法，是把应用数据先全部备份，再把原目录删除。备份当然有价值，可它不等于程序仍能正常工作。应用期待的是原路径上的目录，备份只解决了“以后能不能找回来”，没有解决“现在能不能继续读到”。如果原位置被删除，而程序没有相应的迁移配置，启动时就可能出现空目录、重建索引，甚至覆盖新生成的数据。
我没有把应用草稿和运行数据一股脑搬走，是因为释放几 GB 的收益，不能抵消工作链断掉的风险。真正需要迁移的，应该是冷数据；真正需要保护的，是程序对路径和状态的预期。
复制、核对，再移除
确定分层以后，我把迁移拆成了几个不可省略的动作。先在目标位置复制，不在源目录和目标目录之间做直接剪切。复制完成后，核对文件数量和总字节数；如果有目录层级、隐藏文件或特殊文件，也要确认核对口径没有漏掉它们。
只有当两边一致，才考虑移除原件。这个顺序看起来慢，却给失败留下了退路：复制中断时，源数据还在；核对不一致时，可以继续查差异；只有确认完成后，才释放原来的空间。如果一上来就剪切，传输中断或目标盘短暂不可用时，恢复成本会突然变高。
这里的“核对一致”不是一种形式。文件数能发现明显缺项，字节数能发现部分内容不完整；两者一起看，至少能把最常见的半迁移状态挡在删除之前。对于重要的归档，核对后还要实际打开少量代表性文件，确认它们没有变成只有目录、不能使用的空壳。
迁移的安全边界是先复制、再核对、后移除；任何一步不确定，都先保留原件。
旧路径要保留时再做兼容
如果程序仍然需要沿原路径读取数据，迁移完成后可以在原位置保留软链接，让旧路径指向新的目录。这样做的意义不是把软链接当成魔法，而是保留已有程序的访问方式，减少重新配置和重新索引的范围。
但软链接只能解决路径兼容，不能解决目标位置不存在、外置盘未连接或共享盘不可用的问题。原位置看起来还在，不代表目标数据一定可达。重启、换网络、暂时拔掉外置盘之后，都可能出现“链接还在，内容却打不开”的状态。
所以我会把软链接当成迁移完成后的兼容层，而不是迁移前的保险。先确认目标数据完整，再确认目标位置在日常使用时可访问，最后才替换原目录。对应用数据库和草稿，如果没有明确的恢复方案，我宁可保留在本机，也不为了多释放一些空间去破坏运行链。
这件事表面上是在移动文件，其实是在维护一个约定：程序原来相信某个路径会有数据，我要改变存储位置，但不能悄悄改变这个约定。能保留就保留，不能保证就不动。
这套方法可以怎样复用
以后遇到系统盘告急，我会先做用途清单，再做迁移决定，而不是先打开排序列表。清单至少包含数据用途、访问者、是否可再生、目标位置和恢复方式。只要其中一项说不清，就先把它视为风险项，不做不可逆操作。
具体流程可以压缩成一句话：先按“自动读取、偶尔查阅、可再生缓存”分层；把冷数据放到共享盘，把程序仍需读取的数据放到本机外置盘；复制后核对文件数与字节数；需要兼容旧路径时再留软链接；应用数据库和草稿没有可靠迁移方案就暂不移动。
这个方法并不承诺一次释放最多空间，它承诺的是迁移以后还能继续工作。一个成熟的清理流程，不是把系统盘数字变得好看，而是让数据去到更合适的位置，同时让程序的依赖、人的查阅和失败后的退路都被看见。
我更愿意把它看成一种工作习惯，而不是一个技巧。空间紧张时，人很容易只看眼前的数字；分层则迫使我把“现在占用多少”往后再问一步：它接下来还要被谁使用？当这个问题先得到回答，搬家才不会变成另一种故障。
下次我会怎么做
下次发现系统盘快满，我会先暂停剪切动作，做一次只读盘点，并把候选目录按用途写下来。成片、归档和完成产物先评估是否属于冷数据；应用草稿、会话记录和运行数据先默认需要保留；缓存则单独确认是否可再生。
接着，我会先确定目标位置和恢复方式，再复制，不直接删除。复制结束后核对文件数和字节数，抽查代表性文件；任何不一致都保留源文件继续排查。只有确认目标可用，且程序仍需要旧路径时，才用软链接维持兼容。
如果只是为了多释放一点空间，就必须移动应用数据库或草稿，我会把这个动作判为不划算。空间管理的终点不是空出更多容量，而是在容量、可访问性和恢复能力之间取得可持续的平衡。
这次的经验最后留下了一条很简单的规则：先判断谁需要数据，再决定数据去哪；先保证能找回来，再释放原来的位置。这样下一次面对满盘提醒时，我处理的就不只是一个数字，而是一套不会轻易打断工作的秩序。