关联主题:: Mac、时间机器、Mole-像鼹鼠一样深入挖掘来优化你的 Mac、时间机器备份提示空间不足，怎么删除老旧的备份？
同级:: 2026-08-02_星期日
下一级::
先说结论
Mac 的“系统数据”不是一个可以直接打开的文件夹，而是 macOS 对缓存、日志、临时文件、应用容器、APFS 快照等内容的综合分类。它突然变成几百 GB 时，不要一上来就删除 /System 或者执行 rm -rf。
这次我的 Mac 磁盘总容量约 494GB，系统设置一度显示：
- 系统数据：304.08GB；
- 文稿：约 78GB；
- 可用空间：只剩约 8GB。
最后真正释放空间的关键，不是普通缓存，而是一个位于 Data 卷上的、可清理的 Time Machine 本地快照。删除后，命令行看到 Data 卷可用空间从约 8.7GiB 增加到约 80GiB；储存空间重新计算完成后，系统数据降到 31.5GB，图形界面显示可用空间约 119GB。
一、先用 Mole 清理，但不要期待它解决所有问题
我先运行了 Mole 的预览命令：
mo clean --dry-run预览显示可以清理约 2.57GB，主要包括用户应用缓存、日志、uv/pip/npm/Go 缓存、Homebrew 缓存、VS Code 缓存和一些孤儿应用资源。确认后执行：
mo clean实际释放约 2.86GB，共清理 40 项、12 类内容。这个结果说明 Mole 是一个很好的第一步，但它解决的是“常规缓存和开发工具缓存”，并不会替你删除所有 APFS 快照，也不会擅自处理微信、Telegram、Obsidian 等应用的数据库。
当时 Mole 还提示 Time Machine 备份正在进行，因此跳过了相关清理；需要 sudo 的系统缓存扫描也没有强行执行。这个选择是合理的：磁盘清理最重要的不是“删得多”，而是先知道正在删除什么。
二、重启有用，但重启本身不是清理
第一次清理之后，系统数据仍然很大。我重启 Mac 后，储存空间页面经历了一段“正在计算”的过程，系统数据从 304GB 先变成约 195GB。
这里有两个容易误判的地方：
- macOS 储存空间分类是异步计算的，刚打开页面时数字可能不稳定；
- 重启会结束部分进程、触发系统重新计算和回收，但不会自动删除所有占用空间的内容。
所以，重启值得做，但应该把它理解成“让系统重新整理账本”，不是万能清理按钮。重启后最好等待储存空间页面计算完成，再继续诊断。
三、确认 Time Machine 备份在 NAS，但本地仍可能有快照
我用下面的命令确认 Time Machine 目标：
tmutil destinationinfo结果显示目标类型是 Network，协议是 SMB，目标名称是 NAS 上的 Time Machine0714。也就是说，真正的 Time Machine 备份确实在 NAS 上。
但这不代表 Mac 本地完全没有 Time Machine 数据。macOS 还可能在本机 APFS 卷上创建“本地快照”。它不是一份简单的完整备份副本，而是基于写时复制（Copy-on-Write）的时间点记录：快照会保留仍被旧版本引用的数据块，因此在空间统计中可能表现为已占用空间。
可以用下面的命令检查：
tmutil listlocalsnapshots /
diskutil apfs listSnapshots "/System/Volumes/Data"这次排查发现：
- Data 卷上有一个
2026-08-02-161033的 Time Machine 本地快照； - 该快照标记为
Purgeable: Yes，说明在空间压力下可以回收； - 系统卷上另有 3 个 macOS 更新快照，它们不是普通 Time Machine 本地快照，不能混在一起处理。
因此，“备份在 NAS，为什么本地还占空间”的答案是：NAS 是备份目的地，本地快照是 macOS 为 Time Machine 和系统恢复准备的临时/中间机制，两者可以同时存在。
四、删除本地快照前，先确认备份没有运行
先查看当前 Time Machine 状态：
tmutil status确认没有正在运行的备份后，再针对明确的时间戳删除本地快照：
tmutil deletelocalsnapshots 2026-08-02-161033删除后再次检查：
diskutil apfs listSnapshots "/System/Volumes/Data"
df -h /System/Volumes/Data这次删除成功后，Data 卷上的本地快照消失，可用空间明显增加。整个过程没有删除个人文件，也没有动系统卷上那 3 个 macOS 更新快照。
需要注意
- 只处理明确标记为可清理的本地快照；
- 不要用
rm -rf直接删除 APFS、/System或受保护目录； - NAS 上的
.sparsebundle是另一层备份数据，不要把它和本地快照混为一谈； - 删除本地快照意味着失去该时间点的本地恢复点，但不会删除 NAS 上已有的备份；
- 如果 Time Machine 自动备份仍开启，本地快照未来可能再次出现，这是正常现象。空间紧张时 macOS 通常会尝试自动回收，但储存空间分类不一定会立即刷新。
五、系统数据降下来后，才看得见真正的“大户”
快照清理并等待系统重新计算后，系统数据降到约 31.5GB，剩余空间约 119GB。此时储存空间页面把“应用程序”显示成约 199GB，看起来又像出现了新的问题。
进一步检查发现，/Applications 下所有 .app 程序本体合计只有约 31GB。储存空间里的“应用程序”还包含各个 App 的容器、消息数据库、下载包、更新包和媒体缓存，所以分类数字会远大于 Finder 里看到的 App 图标大小。
这次排查到的后续空间来源包括：
| 来源 | 发现情况 | 建议 |
|---|---|---|
| Xmind 更新包 | ~/Library/Application Support/Xmind/.../auto-updater 约 5.4GB | 退出 Xmind、确认没有更新后再清理旧安装包 |
| 应用通用缓存 | ~/Library/Application Support/Caches 约 2.3GB | 先用 Mole 预览，逐项确认 |
| xbot 更新包 | updater 目录约 1.1GB | 确认应用已退出、没有正在升级后处理 |
| Telegram 数据库 | 单个消息数据库约 6.8GB | 优先用 Telegram 的“数据和存储”清理，不要直接删数据库 |
| 微信数据 | 已发现多组大型消息数据库，合计至少约 10GB | 在微信设置中清理聊天媒体和缓存，先备份重要记录 |
| Obsidian 备份压缩包 | 多个旧备份合计约 7.5GB | 确认 NAS 或其他位置已有备份后再删除重复压缩包 |
其中，Xmind、应用更新包和普通缓存属于相对安全的下一批候选；Telegram、微信数据库和 Obsidian 压缩包则可能包含真正有价值的历史数据，不能当成垃圾批量删除。尤其是“文稿”以及与事件取证有关的视频、音频和资料，只能人工确认后处理。
六、以后遇到“系统数据暴涨”，建议按这个顺序
- 先看储存空间页面是否还在计算，等待几分钟，必要时重启一次；
- 用
df -h判断 APFS 卷是否真的快满，不要只看系统设置里的分类； - 用
mo clean --dry-run查看普通缓存，确认后再执行mo clean； - 用
tmutil destinationinfo确认 Time Machine 是本地磁盘还是 NAS； - 用
tmutil status确认备份空闲，再检查本地快照； - 只删除明确的、可清理的本地 Time Machine 快照；
- 最后再检查“应用程序”分类下的 App 容器、聊天数据库、下载包和更新包；
- 个人文件、聊天记录、备份压缩包和 NAS 备份，始终放到最后人工确认。
这次经验最重要的不是记住某一条删除命令，而是先区分三件事：
- 缓存：可以用 Mole 预览和清理；
- 本地快照：需要用 APFS/Time Machine 工具确认后处理；
- 个人数据：必须先确认备份和用途，不能因为系统把它归在“应用程序”或“系统数据”里就直接删除。
Mac 的储存空间分类只是线索，不是结论。真正可靠的清理流程，应该是“先测量、再定位、后删除，最后复核”。