apfs快照不占额外空间但影响容量显示，关键在判断可删性；需查/system/volumes/data卷而非根卷，用diskutil和tmutil交叉验证快照状态，按时间戳精准清理过期快照。
macos 的 apfs 快照本身不占额外空间，但会影响“系统数据”显示和实际可用容量。真正需要管理的不是快照数量，而是判断哪些能删、何时删、怎么删才安全——脚本只是执行工具，逻辑判断才是关键。
确认快照真实存在位置
很多脚本失败，是因为默认查 / 卷却忽略了 macOS 11+ 的实际存储路径。APFS 快照几乎都落在数据卷 /System/Volumes/Data 上，而非只读的系统根卷。
- 运行 sudo diskutil apfs listSnapshots /System/Volumes/Data —— 显示完整 UUID、大小、Purgeable（是否可删）和 Locked 状态
- 再补一句 sudo tmutil listlocalsnapshots / —— 交叉验证 Time Machine 类快照名（如 com.apple.TimeMachine.2026-06-10-142219）
- 若后者为空，别急着写删除脚本，先用前者确认快照是否真在数据卷上
安全删除：按时间戳精准清理
批量删或通配符删风险高，系统可能正依赖某条快照做增量备份。推荐脚本中只处理明确过期的时间点。
- 提取最近 3 天以外的快照时间戳：sudo tmutil listlocalsnapshots / | grep "com.apple.TimeMachine" | awk -F'-' '{if ($3
- 对每个时间戳执行：sudo tmutil deletelocalsnapshots 时间戳（例如 2026-06-07-091522）
- 成功返回 Deleted local snapshot；失败常见于快照已不存在或名字格式不对，脚本应跳过并继续
紧急腾空间：一键触发系统级回收
当剩余空间低于 10GB 或“系统数据”长期卡在 50GB+，手动逐条删太慢。用 thinlocalsnapshots 是最稳妥的自动化方案。
- 命令：sudo tmutil thinlocalsnapshots / 9999999999999999 1
- 参数 1 表示“保留最少必要快照”，系统自动跳过活跃快照、Time Machine 正在引用的快照、以及 com.apple.os.update 类系统保护快照
- 执行后建议加一句 df -h / 输出到日志，方便对比空间变化
绕过异常：强制清理僵尸快照
断电、升级中断或 NAS 失联后，可能出现 Stale NFS file handle 错误，tmutil 无法识别或删除。这时必须用底层 diskutil。
- 先从 diskutil apfs listSnapshots /System/Volumes/Data 中筛选出 Purgeable: Yes 且命名含 TimeMachine 的快照
- 优先用 UUID 删除（更稳定）：sudo diskutil apfs deleteSnapshot /System/Volumes/Data -uuid XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
- 若只有快照全名（如 com.apple.TimeMachine.2026-06-05-113342.local），加 -name 参数，注意保留 .local 后缀
