必须确认启动卷为APFS格式，否则tmutil localsnapshot会失败；快照默认24小时后自动清理，空间紧张时可能提前被回收。
用 tmutil localsnapshot 手动创建快照前必须确认 APFS 格式
APFS 快照功能只在 APFS 分区上生效，HFS+ 或其他格式执行 tmutil localsnapshot 会静默失败或报错 Operation not supported。打开“磁盘工具”，选中启动卷（如 Macintosh HD），右下角“格式”必须显示 APFS；若为 APFS (Encrypted) 或 APFS (Case-sensitive) 同样可用。非 APFS 卷需先转换——但注意：转换要求至少 20% 空闲空间，且必须提前完整备份，否则风险极高。
tmutil localsnapshot 创建的快照默认 24 小时后自动清理
手动触发的本地快照不是永久存档，它和 Time Machine 自动创建的快照一样，生命周期受系统空间策略控制：
- 默认保留约 24 小时，之后被后台任务回收
- 若磁盘空间紧张（剩余
- 快照名形如
com.apple.TimeMachine.2026-04-14-062533，时间戳精确到秒，可用于后续精准删除 - 运行
tmutil listlocalsnapshots /可立即验证是否创建成功
快照本身不占额外空间，但影响“系统数据”占用可见性
APFS 使用写时复制（CoW），快照共享未修改的数据块，所以 df -h 显示的已用空间不会因快照增加。但 macOS 存储管理界面把这部分共享数据计入“系统数据”或“其他”，导致你感觉“删了几十 GB 文件，可用空间却没涨”。真实释放发生在：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 快照被删除后，且对应数据块不再被任何文件或快照引用时
- Spotlight 完成索引重建后（通常需几分钟）
- 重启后更可靠，尤其当有 iCloud Drive 同步、虚拟机挂起等长期持有句柄的进程时
删除快照后空间没变化？优先跑 diskutil apfs listSnapshots /System/Volumes/Data
tmutil listlocalsnapshots / 有时漏报或延迟刷新，尤其在系统刚升级或异常断电后。此时应改用底层命令确认真实状态：
-
diskutil apfs listSnapshots /System/Volumes/Data显示完整 UUID、大小、Purgeable状态（Yes表示可删） - 若发现大量
Purgeable: No的快照，大概率是系统保护快照（如com.apple.os.update），不可删，否则可能无法启动 - 确认目标快照可删后，用
sudo diskutil apfs deleteSnapshot /System/Volumes/Data -name "快照全名"强制移除，比tmutil deletelocalsnapshots更彻底
快照管理真正的复杂点不在创建或删除命令本身，而在于判断“这个快照到底能不能动”——系统不会告诉你某条快照关联着哪个正在运行的容器或扩展，只能靠命名规则、Purgeable 标志和上下文交叉验证。盲目删掉带 os.update 的快照，或者误删唯一一个未被 Time Machine 同步过的本地快照，都可能导致回滚失败。
