APFS快照不单独占空间但保留历史数据块,长期堆积会占用“系统数据”容量;应通过tmutil或diskutil准确识别可删快照(如TimeMachine及超48小时的os.update快照),避免误删Purgeable: No的系统恢复快照。

macOS 的 APFS 快照本身不单独占空间,但会保留被修改或删除文件的历史版本数据块,当快照长期堆积时,会显著影响“系统数据”占用和可用容量。真正有效的管理不在盲目删除,而在准确识别、按需清理。
查看快照的两种可靠方式
很多用户只运行 sudo tmutil listlocalsnapshots /,结果返回空就以为没快照——其实快照大多挂在数据卷上,而非只读的系统卷 /。
- 先查 Time Machine 类快照:
sudo tmutil listlocalsnapshots /,看是否有com.apple.TimeMachine.2026-xx-xx-xxxxxx格式条目 - 再查全量快照(更关键):
sudo diskutil apfs listSnapshots /System/Volumes/Data,它会列出所有快照的 UUID、创建时间、大小及 Purgeable: Yes/No 状态 - 图形界面辅助:打开“磁盘工具”→“显示”→“显示 APFS 快照”,在边栏选中 Macintosh HD - Data 卷,底部表格即显示全部快照,可添加“专用大小”“Purgeable”等列直观判断
哪些快照可以安全删除
不是所有快照都能删,误删可能影响系统启动或恢复功能。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac,无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启:辅助功能 + 屏幕录制权限
-
可删:前缀为
com.apple.TimeMachine.的本地快照(Time Machine 断连时自动生成),以及升级完成后超过 48 小时的com.apple.os.update.快照(确认系统运行稳定后再操作) -
不可删:标有
*的活跃恢复快照(tmutil listlocalsnapshots /中带星号)、Purgeable: No且含com.apple.os.update的签名系统卷快照——这类是 macOS 启动和恢复所依赖的,强制删除会导致无法进入系统
删除快照的具体操作
优先用温和方式,异常情况再走底层命令。
- 按时间删一个快照:
sudo tmutil deletelocalsnapshots 2026-05-28-142231(只需日期+时间戳,不用前缀) - 紧急腾空间(如剩余不足 10GB):
sudo tmutil thinlocalsnapshots / 9999999999999999 1,数字 1 表示最小保留策略,系统自动清理非活跃快照 - tmutil 报 Stale NFS file handle 或找不到快照时,改用
diskutil:sudo diskutil apfs deleteSnapshot /System/Volumes/Data -name "com.apple.TimeMachine.2026-05-28-142231.local"
或更稳妥地用 UUID:sudo diskutil apfs deleteSnapshot /System/Volumes/Data -uuid XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
删完没释放空间?这是正常现象
APFS 的空间回收存在延迟和依赖条件:
- 快照删除后,对应数据块仅在无任何引用(包括 Spotlight、iCloud 缓存、其他快照)时才真正释放
- 执行命令后建议运行
df -h /查看变化;若无明显上涨,重启一次再检查更可靠 - 第三方清理工具常把共享数据块重复计算为“快照占用 XX GB”,实际并非真实占用,勿轻信其数值










