如何删除 Mac 本地 Time Machine 快照

存储空间发布于 更新于 约 6 分钟

删掉一部 20 GB 的导出，清空废纸篓，可用空间却几乎不动。第一反应往往是装清理工具。更常见的情况是：启动卷上的本地 Time Machine 快照还钉着那些数据块。系统设置里的存储空间把效果揉进系统数据或笼统的「可清除」数字，所以你已经做完该做的事，灰色长条仍旧很大。

这是一篇可复现的说明：APFS 写时复制如何钉住块、怎样用系统命令测量快照、tmutil 实际改什么，以及如何在不动真正备份盘的前提下腾空间。读完后，你应能在几分钟内区分「快照钉住」和「真有大文件夹没找到」。

错误心智模型

很多人把可用空间理解成「看得见的文件之和」。在 APFS 上，更接近「没有任何引用的块」。文件可以离开 Finder，extent 仍被快照引用。只要最后一个引用还在，df 就会继续把这些块算作已用。

口头上常混着三种数：

数字 回答的问题
Finder / 应用显示的「大小」 你仍能看见的命名文件的逻辑大小
df 的已用 / 可用 挂载文件系统按记账规则报告的结果
存储里的「可清除」 系统估计能回收的混合池上界

可清除不是文件夹。它可以包含本地快照、部分缓存、可驱逐的云内容，以及记账余量。工具若承诺「释放 47.2 GB 可清除」却不给出前后 df，就是在猜。

机制：写时复制与快照

Time Machine 创建本地快照时，卷上记录的是当时 extent 的冻结视图。之后的写入分配新块；旧块在仍被快照需要时继续存活。删除文件只去掉现行卷上的指针。

所以这个序列很常见：

  1. 用 df -h / 记下可用空间
  2. 删除一个你可控的大文件，并清空废纸篓
  3. 可用空间几乎不动
  4. tmutil listlocalsnapshots / 仍有条目
  5. 变薄或删除本地快照后，可用空间上升（有时要等几分钟）

Apple 把本地快照写成自动管理：在外接备份之间创建、短期内保留，并在需要空间时变薄。它们方便在未接备份盘时恢复近期版本，不是外接盘上完整 Time Machine 历史的替代品。

现行卷上已删除的文件，因本地快照仍引用相同数据块而继续占盘；变薄快照后块才释放
在 Finder 里删除只去掉现行卷引用。只要还有本地快照指向那些 extent，物理块就不会释放。

本地快照名称通常类似：

com.apple.TimeMachine.2026-07-28-091530.local

.local 后缀一般表示这是盘上的本地快照，而不是备份目标上的条目。

本地、外接与其他快照

类型 位置 怎么处理
/ 上的本地 TM 快照 启动卷 空间紧时用 tmutil 变薄
Time Machine 备份 外接或网络卷 真正历史；不要为内置盘空间抹掉
其他 APFS 快照 同卷，命名不同 只有确认所有者才可删
iCloud 优化存储 云端 + 本地物化 驱逐策略，不是 tmutil

diskutil apfs listSnapshots / 的范围可以大于仅 Time Machine。其他软件也能建 APFS 快照。不要用不明「优化器」乱删非 TM 快照。

APFS 容器划分为用户文件、快照、可清除空间与空闲空间
物理容量由文件、快照、可清除数据与空闲空间构成。系统数据是存储分类，不是一个可整体清空的文件夹。

实验：先测量，再删除

打开终端，记下基线。数字要写下来，靠记忆会骗人。

date
df -h /
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /
diskutil apfs list

怎么读输出

listlocalsnapshots 为空。 问题不在本地 TM 快照。用 du 或树图映射文件夹（找大文件），再看缓存、照片、Docker 或设备备份。

有快照且空间紧张。 钉住很说得通。进入变薄，再复测。

diskutil apfs list 显示容器里有多个卷。 空闲在容器级共享。可能出现「某个卷标签看着满、容器其实还有空间」或反过来。始终看容器空闲，不要只看启动卷标签。

权限错误。 终端可能没有完全磁盘访问去读部分受保护树。这是访问问题，不代表磁盘是空的。

一次可控实验

想在自己机器上证明机制：

  1. 记下 df 可用字节
  2. 把一个可重建的大文件（例如可再下载的磁盘映像）拷到内置卷，再删掉并清空废纸篓
  3. 几秒内再比一次 df
  4. 列出快照
  5. 若空间几乎不动且仍有快照，变薄，等两分钟，再 df

这样就分开了「Finder 里文件没了」和「块已可给新写入使用」。

tmutil 能做什么

先让系统变薄

可用空间只是略紧时，继续用机器即可。装更新、写大文件，或磁盘本身偏满，常会促使系统丢掉最旧的本地快照。这条路径副作用最少，也更能保住较新的恢复点。

按目标空闲量变薄

tmutil thinlocalsnapshots 可请求系统从本地快照回收最多一定量空间。参数随 macOS 版本略有差异，以本机 man tmutil 为准。含义是「尽量从本地快照腾出最多 N 字节」，不是「只删某一个小时」。

适合安装程序需要余量、又仍想尽量保留较新本地恢复点时。

删除该卷上的本地快照

磁盘已经很满，且列表里有条目时：

tmutil deletelocalsnapshots /

部分版本按日期名删除单个本地快照，而不是单一的斜杠形式。以当前系统文档为准，然后务必重列：

tmutil listlocalsnapshots /
df -h /

可用空间可能在数秒到数分钟内上升。APFS 可能异步释放 extent。采两次样。

不要与这些混淆

  • 对备份目标使用 tmutil delete 会删真正备份历史，风险更高
  • 在 Finder 里删 /.MobileBackups 不是受支持的清理路径；用 tmutil 或系统回收
  • 关掉 Time Machine 不是腾本地快照空间的前提，还可能丢掉仍需要的备份策略
  • 需要 root、却说不清 APFS 模型的第三方「快照优化」增加风险，也教不会你用 df 复核

读故事，而不是背数字

假设周末剪了不少片子：

  • 存储显示系统数据约 120 GB，「可清除」写着最多 40 GB
  • 你删了 25 GB 导出并清空废纸篓
  • df 可用大约只涨了 2 GB
  • tmutil listlocalsnapshots / 里还有最近一天的多个 .local

解释：被删导出的大部分仍被本地快照引用。下一步应是变薄本地快照，而不是随机清空 ~/Library。

在 tmutil deletelocalsnapshots /（或一次成功的 thin）之后：

  • 快照列表变空或变短
  • df 可用在几分钟内涨出几十 GB
  • 存储里的系统数据数字可能滞后或重新分类；信 df 和真实能否装得下东西

若快照列表本来就是空的，可用空间仍不动，就不要再跟快照较劲。问题在别处：现行大文件夹、稀疏文件、克隆、同卷废纸篓，或容器里另一个卷。

变薄后空间仍可能不涨

即使本地快照已经没了：

  • 存储估计里大部分其实是其他可清除类（云物化、可再生缓存）
  • 稀疏文件与克隆让逻辑与物理大小分叉（总量为何不一致）
  • 废纸篓仍占同卷空间
  • APFS 容器内另一卷共享空闲池
  • 仍有非 TM 快照或备份目标相关数据

这些各有测量路径。快照只是其中一章。

安全前提

激进变薄前：

  1. 确认外接 Time Machine 或其他近期且打开测过的恢复路径
  2. 接受：你删掉的中间本地版本，在新快照出现前无法离线恢复
  3. 优先文档化的 tmutil，而不是给不出前后可用空间差值的工具

本地快照是正常机制。只有在内置卷已满、且刚删除的数据仍被钉住时，它才变得紧迫。

常见错误

追逐系统数据那个数字。 目标是可用容量，以及机器还能更新、还能存文件，不是灰色块好看。

因为内置盘满就抹外接备份盘。 把本地快照和备份历史搞混了。

因为可清除看起来很大就乱删资源库。 可清除不是安全路径地图。

变薄后立刻量一次就下结论。 等一下，再采一次 df。

忽略容器记账。 一个卷标签不是 APFS 的全貌。

回顾类工具适合什么

Mole 的分析视图擅长标出现行大文件夹，无法把系统数据变成一个可整体清空的目录。快照仍以系统命令为准。

清理视图在存在本地快照时可给出本地快照一行。它不会事先编造每个快照的精确 GB；释放后再测量可用空间变化。这与平台一致：回收是真实的，扫描前的固定承诺往往不是。任何未做前后对比就卖很大「可清除」数字的清理器，是在表演，不是在教人。

操作顺序

  1. 确认仍有真正备份路径
  2. 记录 df -h / 与 tmutil listlocalsnapshots /
  3. 若有快照且空间紧张，用 tmutil 变薄或删除，等待后复测
  4. 若已无快照，测量文件夹并按归属清理缓存或大型用户文件
  5. 确认无误后再清空废纸篓
  6. 再跑之前失败的负载（安装、导出、更新），确认装得下

延伸阅读

本地快照是 APFS 给 Time Machine 在启动盘上提供短期撤销的方式。学会把 tmutil 与 df 一起读，「删了 30 GB 却没变化」就变成可验证的机制，而不是相信恐吓式软件的理由。