Mac 再次提示磁盘快满时，数据卷约 460GiB，已用 409GiB，实际可用只剩 3GiB。排查和清理后，可用空间回到 72GiB。这次最值得记住的是：du 看到的目录大小不能直接相加当作可回收量；APFS 克隆、Docker 虚拟盘和交换空间，都可能让账面数字与 df 的变化不同。
从哪里开始找
先用 df -h /System/Volumes/Data 确认真正的可用空间，再用 du -x -d 1 -h 按目录向下找。第一轮看到的主要占用是：用户目录、~/Library、系统临时目录和废纸篓。继续往下，临时目录里有一组 com.google.Chrome.code_sign_clone，账面上约 52GiB：几十份 Chrome 的应用副本，每份约 1.4GiB。
这不是 Chrome 浏览数据；浏览器资料在另一处。逐个确认副本路径和修改时间后，清掉了 43 份旧副本，保留当时最新的一份。由于 APFS 数据块可能共享，du 的 52GiB 不等于删除后一定能多出 52GiB，实际要以 df 为准。
做过的清理
- 清空废纸篓。里面主要是旧应用副本，清完后实际多出约 22GiB。
- 删除旧的 Chrome 代码签名副本，保留最新的一份；实际多出约 10GiB。
- 用
docker volume prune清掉 370 个未被容器使用的卷。清理前 Docker 报告约 14.85GiB 可回收，清理后只剩一个在用卷；OrbStack 虚拟盘占用也随之下降。 - 清理 npm、pnpm、uv、Go 的可重建缓存，以及几个 Rust 项目的
target/编译产物。下次构建会重新生成这些文件。
整个过程按批次操作，每批之后都重新看 df，最后数据卷可用空间从 3GiB 回到 72GiB。各批次的目录大小和最终净增长不是同一种口径，不做加总推算。
留下的东西
聊天记录、浏览器资料、应用容器和个人文件没有作为缓存处理。巡检工具留下的 Git worktree 也没有直接删除，因为它可能是工作中的检出目录。系统交换空间当时约占 23GiB；它与内存压力有关，不靠手动删除交换文件解决。
这次排查的顺序可以复用：先确认实际可用空间，再按目录定位；区分缓存、副本和真实数据；每清一批都用 df 复核。 数字以磁盘重新统计后的结果为准。
