你的 Mac 磁盘被快照占满，而非文件——教你如何验证

你清空了 40 GB 的视频文件，倒空了废纸篓，可用空间的数字却几乎纹丝不动。或者反过来：Finder 兴高采烈地报告还有 300 GB 可用，macOS 27 安装程序却因为空间不足而拒绝启动。这其实是同一个现象。在 APFS 上，「可用空间」是一个可以协商的数字，而那些你在 Finder 里看不到的部分——快照、可清除内容，以及共享同一个容器的兄弟卷——正是差异所在。随着 9 月 14 日重大版本升级的到来，弄清楚如何解读真实的数字就显得很有必要了。

核心要点

• df 和 Finder 从设计上就会「撒谎」。 安装程序真正关心的数字是 APFS 容器的可用空间，用 diskutil info / 才能读到。
• 你的系统卷上有一个绝对不能删除的快照——也就是你启动所用的、经密封签名的系统卷。它会出现在 diskutil 里，但不会出现在 tmutil 里，这个差异就是全部诊断依据。
• Time Machine 本地快照通常才是空间消失的元凶。 它们会在 24 小时后被删除，或者在空间不足时被清理，但这个「不足」的阈值往往比你期望的要低。
• 可清除空间是真实存在的空间，macOS 会在压力之下释放它——但一次重大升级未必能在恰当的时机制造出恰当的压力。
• 容器里的其他卷同样占用空间。 在这台 Mac 上，Preboot 占用 9 GB，VM 卷有 18 GB 的交换空间，这两者都不会出现在 Finder 的任何地方。

四个数字，同一块磁盘

先看清这个差异，而不是急着质疑它。在这台运行 macOS 26.5.2、配备 1 TB SSD 的 Mac 上：

$ df -h / /System/Volumes/Data
Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   395Gi     3%    /
/dev/disk3s5     926Gi   493Gi   395Gi    56%    /System/Volumes/Data

两个卷都自称有 926 GiB，都报告着相同的 395 GiB 可用空间。两者都没有错，但也都不是真相：APFS 卷共享同一个容器，并在其中动态增长，所以「大小」其实是容器的大小，「可用」其实是容器的可用空间，只是在每个卷上都重复报了一遍。

现在直接问容器本身：

$ diskutil apfs list disk3 | grep -E "Capacity|Volume Disk|Consumed"
    Size (Capacity Ceiling):      994662584320 B (994.7 GB)
    Capacity In Use By Volumes:   570712170496 B (570.7 GB) (57.4% used)
    Capacity Not Allocated:       423950413824 B (424.0 GB) (42.6% free)
    |   APFS Volume Disk (Role):   disk3s1 (System)
    |   Capacity Consumed:         12568809472 B (12.6 GB)
    |   APFS Volume Disk (Role):   disk3s2 (Preboot)
    |   Capacity Consumed:         8995532800 B (9.0 GB)
    |   APFS Volume Disk (Role):   disk3s3 (Recovery)
    |   Capacity Consumed:         1304084480 B (1.3 GB)
    |   APFS Volume Disk (Role):   disk3s5 (Data)
    |   Capacity Consumed:         529380937728 B (529.4 GB)
        APFS Volume Disk (Role):   disk3s6 (VM)
        Capacity Consumed:         18253713408 B (18.3 GB)

这才是老实的账目。一共五个卷，其中只有一个——Data，529 GB——是你能在 Finder 里浏览到的。Preboot 占了 9 GB，VM 卷占了 18 GB。 两者加起来比大多数人的「文稿」文件夹还大，而 Mac 上任何一个存储管理界面都不会把它们展示给你看。

安装程序真正在意的，只有这一个数字：

$ diskutil info / | grep "Container Free Space"
   Container Free Space:      423.9 GB (423947014144 Bytes)

以这个数字为准。如果它和 Finder 报的数字相差几十 GB，下面的内容会解释这些差异都去了哪里。

那个你绝对不能删除的快照

运行这个看似显而易见的命令，结果会让人有点心慌：

$ diskutil apfs listSnapshots /
Snapshot for disk3s1s1 (1 found)
|
+-- B8B12570-09B5-402F-99BB-F383487AD69D
    Name:        com.apple.os.update-5B92CE4BA1034457A0921532291F4A4AD939CBE...
    XID:         17495484
    Purgeable:   No
    NOTE:        This snapshot limits the minimum size of APFS Container disk3

一个快照，标记为不可清除，还被明确说明会限制容器的最小体积。很容易就会认定，正是它在吃掉你的磁盘空间。

但并不是。它其实是你正在运行的操作系统本身。

自 macOS 11 起，系统卷会被密封并进行加密验证，Mac 启动时并不会直接启动这个卷本身——而是启动它的一个快照。diskutil apfs list 直接说明了这一点：

|   APFS Volume Disk (Role):   disk3s1 (System)
|   Snapshot:                  B8B12570-09B5-402F-99BB-F383487AD69D
|   Snapshot Disk:             disk3s1s1
|   Snapshot Mount Point:      /
|   Snapshot Sealed:           Yes

Snapshot Sealed: Yes，挂载在 /。com.apple.os.update- 这个前缀，是系统更新时创建的快照所使用的命名规则。删除它不是一次清理操作，而是在删除正在运行的系统。macOS 通常会拒绝执行，但「通常」这个词，可不是你希望夹在自己和一台无法启动的 Mac 之间的词。

要把它和「可以删除」的快照区分开，关键线索是：

$ tmutil listlocalsnapshots /
Snapshots for disk /:

$ tmutil listlocalsnapshots /System/Volumes/Data
Snapshots for disk /System/Volumes/Data:

两个都是空的。tmutil 只报告 Time Machine 快照——也就是为备份而创建、可以安全精简的那种。diskutil 会报告所有 APFS 快照，包括那个密封的系统快照。如果 diskutil 显示有快照而 tmutil 没有，那它就轮不到你来删。

经验法则：以 tmutil 显示的内容作为行动依据。diskutil 的输出只用来理解情况，不用来做决定。

真正吃掉你磁盘空间的快照

Time Machine 不只在备份磁盘上创建快照，也会在 Mac 本机上创建本地快照，而这些快照通常就是「80 GB 去哪了」这个问题的答案。

原理很简单，后果却不简单。快照会保存某一时刻卷的状态。之后再编辑一个文件，原来的数据块就必须和新的数据块一起被保留下来。删除一个在拍摄快照时就已存在的 20 GB 视频，空间并不会被释放——快照仍然引用着它。唯一的例外是那些在两次快照之间「既被创建又被删除」的文件，它们才是真正消失、无法恢复的。

苹果的清理机制既按时间也按压力触发：超过 24 小时的快照会被移除，而在可用空间严重不足时，更早的快照也会被清除。在这两条规则之间，一台开着 Time Machine 定期备份、又经历了忙碌一天文件变动的 Mac，可能会一直占着几十 GB 的空间，直到时间或者压力阈值触发才会释放。

这台 Mac 没有配置任何 Time Machine 备份目的地：

$ tmutil destinationinfo
tmutil: No destinations configured.

——这正是它的快照列表为空、Data 卷显示 No snapshots for disk3s5 的原因。如果你的 Mac 配置了备份目的地（而且理应如此——参见当前的备份策略指南），那大概率会看到好几个快照。

在 Disk Utility 中查看

如果你不想用终端：打开 Disk Utility，选择显示 → 显示所有设备，选中 Data 卷，再打开显示 → 显示 APFS 快照。你会看到一份带大小的列表，还能通过右键菜单逐个删除快照。Howard Oakley 的建议值得重复一遍——保留最近的那一个，因为一次性删光所有快照，会让 Time Machine 在下次运行时被迫做一次完整备份。

有计划地精简快照

官方支持的回收快照空间的方式是 thinlocalsnapshots，它接受一个挂载点、一个希望释放的字节数，以及一个 1 到 4 的紧急程度：

# Ask macOS to free roughly 20 GB from Data volume snapshots, highest urgency
sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4

紧急程度 4 是最激进的选项，必要时会删掉除最近一个之外的所有快照。这本来就是 macOS 在空间压力下会对自己做的事，手动执行只是提前做了而已。

如果想删除某个特定快照，而不是按卷整体精简：

# List them first
tmutil listlocalsnapshots /System/Volumes/Data

# Delete one by its date stamp
sudo tmutil deletelocalsnapshots 2026-09-10-140233

还有一个更底层的等效命令，可以通过 UUID、XID 或名称操作任意 APFS 快照：

diskutil apfs deleteSnapshot disk3s5 -uuid <snapshot-UUID>

能用 tmutil 就尽量用它。diskutil apfs deleteSnapshot 很乐意让你指向错误的卷，而这里所谓「错误的卷」，指的就是你启动所用的那个卷。

「可清除空间」到底是什么意思

macOS 会把一部分空间报告为「可清除」：也就是磁盘写满时，系统准备自动删除的内容。这包括超过保留期的快照、已经存在于云端的 iCloud 缓存文件、已上传的 Photos 原图、下载过的媒体文件，以及各种缓存。

可清除空间确实是能被拿回来的——但这个回收过程是被动的。只有当有东西真正需要空间时，macOS 才会释放它，而且这个需求还得以 macOS 能识别的形式出现。一次大型的 cp 操作会触发它；而一个在写入任何东西之前就先检查可用空间、不够就直接拒绝的安装程序，可能触发不了。

这正是升级当天最典型的失败模式：数百 GB 的可清除空间摆在那里，安装程序却怎么都不肯启动，也没有明显的办法说服系统采取行动。一个简单粗暴又安全的解决办法，是主动制造真实的压力：

# Write a large file to force macOS to reclaim purgeable space, then delete it
mkfile -n 30g ~/Desktop/ballast
rm ~/Desktop/ballast

mkfile -n 创建的是一个稀疏文件，所以写入本身很快；真正触发回收的是这次空间分配。一旦可用空间的数字发生变化，就立刻把这个文件删掉。

没人提起的那些卷

容器里的五个卷中，有两个值得仔细看看，因为它们会不断变大，却没人会想起它们。

Preboot——这台 Mac 上是 9.0 GB。 它保存着这个容器曾经安装过的每一个操作系统的启动时资源，包括恢复环境和每个卷各自的加密材料。它会随着每次重大升级而增长，也不会被自动清理。它同样不适合手动清理：删错东西会导致 Mac 无法启动。不妨把它当作你做过的那些升级所付出的固定成本。

VM——这台 Mac 上是 18.3 GB。 这是交换空间。你可以准确看到里面装的是什么：

$ ls -lh /System/Volumes/VM/
-rw-------  1 root  wheel   1.0G ... swapfile0
-rw-------  1 root  wheel   1.0G ... swapfile1
-rw-------  1 root  wheel   1.0G ... swapfile10
...

$ sysctl vm.swapusage
vm.swapusage: total = 17408.00M  used = 16258.81M  free = 1149.19M  (encrypted)

十七个 1 GB 的交换文件，其中 16 GB 正在使用。macOS 会按需增长交换空间，却不会积极地缩减它；重启是回收它最可靠的方式。如果升级前空间紧张，重启 Mac 并不是什么迷信做法——对一台已经开机好几周的机器来说，它确实能实实在在地释放好几个 GB。

macOS 27 需要多少空间？

苹果官方给出的重大升级最低空间要求，历来在 25 到 45 GB 之间，具体取决于起始版本，而完整安装程序本身大约就有 17 GB——根据安装程序目录，Tahoe 的安装包是 17,953,734 KiB，Golden Gate 大概率也是同一量级。

实际需要的数字要比官方标注的高。在开始重大升级之前，建议预留60 GB 的容器可用空间，理由有三个：安装程序的下载、安装过程本身需要的工作空间，以及 macOS 在升级之前为你的系统拍摄的那个快照——它在升级过程中是没法被精简的。

去检查这个数字，不要靠猜：

diskutil info / | grep "Container Free Space"

另一个过于乐观的数字：iCloud 和 Photos

有两个功能会刻意用一种「讨好」磁盘的方式来汇报空间。

**iCloud Drive 的「优化 Mac 储存空间」**会清除掉那些你最近没用过的文件内容，只留下一个按需下载的占位文件。Finder 显示的文件大小是完整的；磁盘上实际占用的空间却几乎为零。这本来是件好事，直到安装程序问起究竟还有多少空间——因为这些被清除的内容是被算作「可清除」而不是「可用」的。

**Photos 的「优化 Mac 储存空间」**对原图做的是同样的事，本地只保留体积更小的版本。一个 200 GB 的照片库，在磁盘上可能只占 30 GB，而如果你在错误的时机打开了错误的视图，它还可能悄悄地大批量重新下载。

这两个功能本身都没问题，不用去「修复」它们。但它们正是一台 Mac 明明什么都没做，却能从「空间充裕」变成「磁盘已满」的原因，也是上周测得的可用空间数字到今天已经毫无参考价值的原因。请在升级前立刻测量，而不是提前一晚。

升级前，用五条命令做一次空间审查

按顺序运行下面这些命令，不到一分钟你就能清楚知道自己的处境：

# 1. The number that matters
diskutil info / | grep "Container Free Space"

# 2. Every volume in the container, with what it is consuming
diskutil apfs list $(diskutil info / | awk '/Part of Whole/ {print $4}') | grep -E "Capacity|Volume Disk"

# 3. Snapshots that are actually yours to remove
tmutil listlocalsnapshots /System/Volumes/Data

# 4. Swap, which a restart returns
sysctl vm.swapusage

# 5. The largest directories in your home folder
du -sh ~/* 2>/dev/null | sort -rh | head -10

如果第 1 步的结果超过 60 GB，就可以停下来了——你已经准备好了。如果没有，第 2 到第 5 步会告诉你该从四个来源中的哪一个下手，大致是按「风险最小、回收最多」的顺序排列的。

按安全程度排序的空间回收方法

1. 重启。 释放交换空间、清除缓存、移除部分快照。只花两分钟，通常能回收 10 到 20 GB。
2. 精简 Time Machine 快照。 sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4。安全、官方支持，而且从「下次备份会重新创建所需内容」这个意义上说是可逆的。
3. 清空废纸篓，包括 Photos 和 Mail 里的废纸篓——被删除的项目会在应用内的废纸篓里保留 30 天。
4. 强制回收可清除空间，如果数字依然对不上，就用前面提到的「压舱文件」技巧。
5. 开发者缓存（如果适用）。 在这台 Mac 上，/System/Library/AssetsV2 总共占了 25 GB——其中 16 GB 是 iOS 模拟器运行时环境。在一台日常开发用的机器上，Xcode 的 derived data、device support 和归档文件通常会额外占用 50 GB 以上。Xcode 自带的「设置 → Components」面板可以干净地移除模拟器运行时环境。
6. 你自己名下真正的大文件。 存储分析工具找起来比手动浏览快得多。如果磁盘满了却找不到任何原因，隐藏的根目录日志是另一个该看的地方。
7. 转移到外部存储。 当磁盘确实太小时，这是那个又慢又正确的答案。

不要做的事

• 不要删除系统卷上那个 com.apple.os.update- 快照。 它就是正在运行的操作系统。
• 不要对 /System/Volumes/ 下的任何内容执行 rm -rf。 Preboot、VM 和 Recovery 都是承重结构。
• 不要为了「省空间」而关闭 Time Machine 本地快照。 这会让你失去回滚一次糟糕更新的能力——而这恰恰是升级那一周你最需要的安全网。
• 不要为此安装清理类应用。 以上所有操作都是系统自带的命令。一个拥有完全磁盘访问权限、承诺通过删除系统文件来释放空间的第三方工具，其风险比磁盘已满本身还要大。
• 不要手动删除交换文件。 macOS 会重新创建它们，而删除一个正在使用中的交换文件会直接导致系统崩溃。

常见问题排查

tmutil thinlocalsnapshots 报告成功，但空间并没有被释放

它删除的那些快照，引用的数据块同时也被其他快照引用着。在多个相互重叠的快照中删掉其中一个，不会释放任何空间；删掉最后一个才会一次性全部释放。可以用紧急程度 4 重新运行一次，或者逐个删除剩下的快照。

Disk Utility 没有显示任何快照，但空间依然缺失

那问题就不在快照上。去检查容器里各个卷的空间分布——Preboot 和 VM 通常是意外的惊喜来源——再检查可清除空间。一台拥有大型 iCloud Photos 资料库的 Mac，还会持有一些被优化过的原图，它们汇报的数字有时会显得很奇怪。

安装程序说空间不够，但 diskutil 显示空间充足

先确认你看的是容器而不是某个卷，并且看的是内部磁盘而不是外部磁盘。如果两边都显示空间充足，那失败的原因通常是别的问题披着「空间不足」的外衣——第三方 kext 授权失败就是常见的一种。发布首日升级指南里介绍了 kext 检查方法。

空间一夜之间不断消失

是 Time Machine 运行了。这是系统在正常工作。如果文件变动量确实大得不合理，应该去查是什么在写入——比如一个不断重写大文件的同步客户端、一个虚拟机磁盘镜像，或者一个数据库——而不是去怀疑 Time Machine 本身。

删除快照后 Mac 无法启动

进入 Recovery 模式，如果还留有更早的快照，就用 Time Machine 系统恢复功能回滚到那个快照；如果没有，就在现有系统上原地重装 macOS，这样可以保留 Data 卷。「绝不删除密封快照」这条规则存在的意义，正是为了防止走到这一步。

常见问答

APFS 快照算是一种备份吗？

不算。快照和它所引用的数据存在同一块磁盘上。一旦 SSD 出故障，快照也会跟着一起失效。它们能防范的是操作失误和糟糕的更新，而不是硬件故障。真正的备份应该存在别的地方——参见备份策略指南。

升级到 macOS 27 之前应该删除快照吗？

应该精简它们，而不是全部删除，并且保留最近的一个。升级过程本身会为你升级前的系统创建一个全新的快照，一旦出了问题，你需要的正是这一个。

为什么 Finder 显示的可用空间数字不一样？

Finder 报告的是卷的可用空间，其中包含了可清除内容，是一个偏乐观的数字。diskutil info / 报告的是容器真实的可用空间。涉及安装程序时，请以后者为准。

我能阻止 macOS 创建本地快照吗？

你可以彻底关闭 Time Machine 来阻止它们，但这是一笔划不来的交易。24 小时的保留期加上自动的压力精简机制，意味着在一台健康的 Mac 上，快照本身就是自我限制的。

Preboot 占用 9 GB 正常吗？

对于一台经历过好几次重大升级的 Mac 来说，这个数字偏高，但不至于令人担心。它会随着容器承载过的每一次系统安装而增长。目前没有官方支持的方式去精简它，也没有必要尝试。

重启真的能释放空间吗？

是的，效果实实在在。交换空间是主要贡献者——这台 Mac 上是 18 GB——此外还有缓存和过期快照。这是最该先尝试的一步，也是唯一不需要付出任何代价的一步。

结语

Finder 的可用空间数字，是一份写来让人安心的摘要；容器的数字，才是决定周一那次升级能不能启动的那个数字。二者之间的差距，来自你可以精简的快照、macOS 会在压力下释放的可清除内容，以及两个看不见的卷——它们不过是运行一台现代 Mac 所必须付出的成本。

如果只从这篇文章里记住一条命令，那就是 diskutil info / | grep "Container Free Space"。文章里其余的内容，都是在解释为什么这个数字会和你预期的不一样——但它才是那个不会出错的数字。

相关阅读：macOS 27 Golden Gate 发布首日升级指南 · 为什么 macOS 27 没有出现在软件更新里 · 占满磁盘的隐藏根目录日志 · Time Machine 故障排查