Time Machine 本地快照：为什么“系统数据”会一夜之间暴涨

你腾出了 40 GB 空间，第二天早上再看储存空间设置，“系统数据”却在一夜之间悄悄涨回了 20 GB，看不出任何明显原因。这几乎总是 Time Machine 本地快照在作祟，而且大多数人根本不知道有这个功能存在——它完全不需要连接备份磁盘就能运作。

本地快照到底是什么

从 macOS Sierra 开始，Time Machine 会即使在没有插上 Time Machine 备份磁盘的情况下，每小时对你的内置硬盘做一次 APFS 快照。这么设计的想法是：如果你的 Time Capsule 或外部硬盘没有连接——对笔记本来说这是常态——你依然拥有每小时一个的还原点，直到磁盘重新连接、真正的备份发生为止。

问题在于：在一块变动频繁的磁盘上——你在编译、下载、删除大文件——每个快照都会保留自它被创建以来所有改动的差异数据，而 macOS 的自动精简清理并不总能跟上你产生新数据的速度。在一台高强度构建工作的开发者机器上，快照真能在 macOS 顾得上清掉最老的那些之前，先吃掉几十 GB 空间。

看看到底有些什么

tmutil listlocalsnapshots /

这会按日期列出每一个本地快照。如果你看到过去一周里有十几个甚至更多，那就是压舱的“死重”所在。

想看看实际涉及多少磁盘空间——这条命令要跑一两分钟，因为它是在直接遍历 APFS 元数据：

tmutil listlocalsnapshotdates /
diskutil apfs list   # shows "Capacity in Use by Snapshots" near the bottom

清除快照

macOS 本该在磁盘空间紧张时自动清除本地快照——但这里的“自动”意味着只有在可用空间跌到危急水平时才会触发，对大多数人来说，也就意味着在问题真正出现之前永远不会触发。你可以手动强制执行：

# Delete a specific snapshot by date (from listlocalsnapshotdates)
tmutil deletelocalsnapshots 2026-08-28-140023

# Or ask macOS to purge as much as it's willing to, immediately
tmutil thinlocalsnapshots / 10000000000 4

thinlocalsnapshots 命令的参数分别是目标字节数和紧急程度（1–4，4 最激进）——macOS 把这当作一个请求，而不是保证，它会拒绝精简到自己认为不安全的最低限度以下。实际使用中，这通常能回收大部分可用的空间。

这样做安全吗？ 安全，但有一个前提：如果你没有定期连接外部 Time Machine 磁盘，本地快照就是你唯一的还原点。如果你实际上把本地快照当作自己的备份策略在用——很多人是这样，只是自己没意识到——清除它们就会失去回滚到昨天的能力。如果你在外部硬盘或网络共享上有一份真实、最新的 Time Machine 备份，那本地快照就是纯粹的冗余，可以放心清除。

为什么这和本系列里的其他内容都不一样

这些指南里讲到的其他每一种缓存——DerivedData、node_modules、包管理器缓存——从被创建的那一刻起就是死重：从来没有人会把它当作数据来读取，它只是一条性能捷径。本地快照是这里唯一一个真正在做有用的事的分类（让你恢复三小时前删掉的文件），这也正是为什么 macOS 不让你彻底关掉这个功能——你只能要求它更激进地精简，或者删除特定的快照。

如果你想从源头上阻止积累，而不是反复手动清理，唯一的杠杆就是定期连接一块真正的 Time Machine 备份磁盘——一旦真实备份完成，比这份备份更旧的本地快照，对 macOS 自己的自动精简机制来说，就变得容易处理得多。

上面的命令免费，也确实管用。DevCruft 是一款正在开发中的免费 Mac 应用，设计上会把本地快照占用的空间和其他所有吃掉你磁盘空间的东西一起显示出来，让“系统数据”不再是一个神秘数字，而是变成一个具体的、可以采取行动的条目。想在它推出时收到通知，可以加入候补名单。

关于 macOS “系统数据”分类里还藏着什么，可以看看完整的系统数据拆解。