清掉约 52 GiB 旧文件后，我才弄懂 worktree 占了多少空间

Mac 剩下的空间越来越少，我先让 Claude 帮忙列了一张大目录清单。看到 Codex 的项目目录、worktree 和旧归档排在前面，我把清理重点放到了这些文件上。

这次从 2026 年 10 月 22 日整理到 23 日，一共清理了 298 个目录和 26 个旧安装文件。按这些原文件实际占用的记录合计，约 51.95 GiB，也就是标题里的约 52 GiB。其中，第一轮 101 个干净 worktree 约占 11.13 GiB；剩下的还有旧项目、历史归档和安装包。

我原本只是想腾空间，清到一半却追着问了一句：「没看懂，你是要删了还是上传到 GitHub 还是上传到小米智能存储里」

这句问清楚之后，后面的清理才有了明确的顺序。

worktree 是项目副本，但里面未必只有重复文件

我以前看到一堆名字差不多的项目目录，很难判断哪个还有用。worktree 可以先理解为同一个 Git 仓库另外展开的一份工作目录。它方便多个任务分别改代码，也会在本机留下各自的文件。

关联的 worktree 会共享仓库中的部分 Git 数据，但工作目录里的代码、依赖和构建产物仍会占空间。项目做完了，目录不一定跟着消失；如果平时一直开新任务，却很少整理旧任务，回头看就会积下一大堆。Git 官方也区分主工作区和关联工作区，移除工作区有专门的命令。Git worktree 文档

不过，「看起来是副本」不能直接等同于「可以删」。里面可能有还没提交的修改、没被 Git 跟踪的文件，也可能有别的项目仍在引用它。

这次我让 Codex 先核对每个目录的状态：改动有没有保存、提交还在不在、是否仍被任务或进程使用、其他目录是否依赖它。核对完，再分批处理。

第一批删掉的，是 101 个已经核对过的干净副本

第一轮处理了 101 个符合条件的 worktree，原文件占用约 11.13 GiB。用的是 Git 自己的 worktree 移除方式，没有强制删除。

这些副本没有需要另外保存的未提交成果，主仓库、分支和已有提交都保留。删除后又核对了一遍仓库引用和相关提交，确认它们仍然存在。这一批没有另外传到小米存储。

这里的「清理」就是移除本机多余的工作目录。它没有把代码上传到 GitHub，也没有把主项目整个删掉。后来需要保留的旧文件，走的才是备份到小米存储的流程。

我当时反复问清楚这件事，是因为「归档」「移除」「清理」听起来都差不多，但我需要知道：文件现在在哪，以后要用时从哪里找回来。

有改动的旧项目，先搬到小米存储

后面几轮就没那么简单了。有些目录里留着改动，有些是历史项目和旧备份，还有一些 Git 数据与别的目录有关系。

我的要求一直很具体：需要保留的先备份到小米，验证完整，再删本机。文件夹名字也要弄清楚。

Codex 按批次建立文件清单，把要保留的内容打成加密包，再上传到小米智能存储。这里保存的范围包括未提交文件和需要保留的其他内容，不能只看 Git 已经提交了什么。

涉及共享 Git 数据的部分，还另外准备了能够独立携带所需历史的 Git bundle，并在空仓库中验证它们不依赖原来的对象库。bundle 管的是 Git 对象和引用，未提交文件还要靠完整文件备份保存。Git bundle 文档

有改动的 worktree 移除时涉及强制选项，我是在对应备份通过校验后，按明确的目录批次同意删除的。这个选项只用在已经核对过的对象上，没有拿它去批量扫掉所有旧目录。

上传完成以后，我还要求下载回来验一次

小米客户端显示上传完成，只能说明传输这一步结束了。我更在意的是：这个包以后还能不能解开，里面是不是少了东西。

所以每一批上传后，都重新下载一份，先对比加密包的大小和 SHA-256，再解密，逐项核对里面的文件。SHA-256 可以理解为根据内容计算出的校验值，用来发现前后内容是否变化。这次还核对了文件权限、符号链接指向等信息。

删除前，Codex 再查本机原文件有没有新的变化、是否仍在被使用。碰到状态变了的，先留下。小米上的备份验证通过，也不代表可以忽略这最后一次复查。

整个过程共完成了 8 个加密包的回下载校验。确认的是备份包及所列文件的完整性，还有相关 Git bundle 的独立性；没有把每个旧项目都重新部署运行一遍，不能把它说成所有项目都做过完整恢复演练。

文件夹名字，要让过几个月的自己也看得懂

我特意提醒了好几次，名字要弄清楚。只放一个叫「backup」的大压缩包，过几个月打开，还是不知道对应哪个项目。

这次按日期和内容分组，再配一份原目录与备份包的对应清单、恢复说明和校验结果。像「第三轮-历史项目与旧备份」「第四轮-旧安装包26份」，看名字就能大致知道里面是什么。

恢复口令是在本机终端里输入的。加密包保存好了，恢复密钥和口令也得妥善留存；它们丢了，包还在也不等于能恢复。

备份、下载、验证都会产生临时文件。确认远端备份和回下载校验通过、清理结束后，Codex 也把本次生成的本地中转副本清掉了，避免刚腾出的空间又被它们占回去。

四轮到底清了多少

下面统计的是被清理原文件的占用，不把备份过程中临时生成、随后删除的文件重复加进去。

合计按原始字节数计算后再四舍五入，所以和表里几项已经保留两位小数的数字相加会差 0.01 GiB。这里用的是 GiB，1 GiB 等于 1,073,741,824 字节；约 51.95 GiB 对应约 55.78 GB。

最开始记录的可用空间约 6 GiB，收尾时约 100 GiB。但这段时间还有其他清理和文件转移，不能把可用空间增加的全部数量都算给这次操作。能按清单核实的，就是上面这些原文件占用。

第四轮的 26 个安装文件约占 2.66 GiB。删的是旧安装包，已经安装好的应用继续保留。当时仍然挂载着的安装磁盘也没有混进去删。

有些大文件，这次仍然留在电脑上

大文件列表里还有聊天记录、浏览器资料、虚拟机磁盘、动态壁纸和 Git 历史文件。它们很大，却不能都按缓存处理。

这次查到仍被使用的目录、仍有共享关系的 Git 数据，都保留了。有一个旧备份的 Git 状态无法正常读取，也没有为了凑出更大的清理数字就直接删除。

我现在再看那些 worktree，至少知道该让助手回答什么：这个目录还有没有未保存的成果，谁还在用它，删了以后从哪里恢复。只回答「大部分应该没用了」，我不会据此让它整批删掉。

以后再让 AI 帮我清理，我会先把要求写成这样：

先列出准备清理的目录、占用和保留理由。需要留存的先备份到指定存储，下载回来核对完整性；删除前再查文件变化和占用。保留主仓库、分支和仍在使用的内容。最后分别报告原文件清理量、临时文件清理量和当前可用空间，别把它们加成一个数字。

这次旧文件已经清掉，小米上的加密备份和清单还在。下次需要找回某个旧项目，我可以先查它对应哪一包，再按恢复说明取回来。