审计方法#

最大的发现：291 GB 的幽灵文件#

审计第一版用 stat -f %z 统计大文件，汇总出 647 GB——我心想这也太多了。

后来对比另一份审计（用 du -sk / stat -f %b 统计物理占用），发现数字对不上：

220 个文件的物理占用是 0 字节。

这些文件在 Finder 里看起来完全正常——有图标、有大小、双击能打开（会触发下载）。但它们已经被 macOS 的 “Optimize Mac Storage” 功能 evict 到了 iCloud，本地只留了一个 0 字节的占位符。stat -f %z（逻辑大小）照样报 22 GB，但 stat -f %b（512 字节块数）返回 0。

举几个典型的：

1
stat -f "logical=%z  blocks=%b" ~/Documents/movies/fcp_iww2proj4.zip

1
logical=24502598175  blocks=0

一个 22.8 GB 的 Final Cut Pro 项目包——物理占用 0。它在 Documents 文件夹里（不是 iCloud Drive），但因为 macOS 开启了 Desktop & Documents Sync，这个文件已经被 evict 到云端了。

同样的情况发生在 ~/Library/Mobile Documents/com~apple~CloudDocs/Archives/LargeDownloads/ 下面所有 Blender 大场景文件（80+ GB 逻辑）、ISO 镜像、屏幕录制——全部是 0 字节占位符。

教训

在 APFS + iCloud 环境下，所有清理决策必须基于物理大小。逻辑大小只能用于发现文件数量和分布，不能用于估算可释放空间。du -sk 给的是物理大小，stat -f %z 给的是逻辑大小——两者在 iCloud 管理的文件上可以差出整个数量级。

另外一个有意思的例子是 Claude 桌面客户端的 VM bundle：

1
logical=10737418240  blocks=16153376
2
# 10 GB 逻辑 → 7.7 GB 物理

这是 APFS 稀疏文件——文件内部有大量未写入的区域，APFS 不为它们分配物理块。

真正占空间的是什么#

排除占位符后，真正占盘的大头：

iOS Simulator Runtimes 是个容易被忽略的大头——它们不在 ~/Library 里，而是作为独立的 APFS 容器挂载在 /Library/Developer/CoreSimulator/Volumes/。df -h 能看到 disk5 到 disk19 这些卷。我装了 iOS 18.1、18.2、26.2、26.4 四个版本加上两个 watchOS，合计 107 GB。

意外收获：OpenWrt 路由器也满了#

清理 Mac 之余，本来想把一些重要文件 rsync 到路由器的外挂硬盘上做个冷备份。SSH 进去一看，备份还没开始就 abort 了——这台跑 OpenWrt 的飞凡 N1 盒子（也是 TimeMachine 的备份目标），Docker 数据分区已经满了：

1
df -h /mnt/mmcblk2p4

1
Filesystem      Size  Used  Available  Use%  Mounted on
2
/dev/mmcblk2p4  4.5G  4.5G         0  100%  /mnt/mmcblk2p4

Docker 数据分区 100% 满。

查了一下原因：

1
du -sk /mnt/mmcblk2p4/docker/containers/* | sort -n | tail -3

最大的容器日志：

node_exporter 每 15 秒报一条相同的错误：

1
collector failed name=arp err="could not get ARP entries:
2
rtnetlink NeighMessage has a wrong attribute data length"

OpenWrt 5.15 内核的 netlink 消息格式和 node_exporter v1.7.0 预期的对不上，ARP collector 每次采集都失败，每次失败都写一行日志。跑了 14 个月没人管，日志涨到 422 MB。加上 Prometheus 自己的日志 212 MB，两个加起来把 4.5 GB 的分区塞满了。

修法很简单——截断日志 + prune dangling 镜像，从 100% 降到 82%。然后改 /etc/docker/daemon.json 加 log-opts 的 max-size 和 max-file，重启 dockerd 让 rotation 生效。

清理过程#

回到 Mac。逐类过了一遍：

1
xcrun simctl runtime delete <uuid>

1
tmutil listlocalsnapshots /

1
com.apple.TimeMachine.2026-05-24-121559.local
2
com.apple.TimeMachine.2026-05-25-153221.local
3
com.apple.os.update-...  # 3 个 OS update 快照

1
tmutil deletelocalsnapshots 2026-05-24-121559
2
tmutil deletelocalsnapshots 2026-05-25-153221

最终结果#

System Report 报的 457 GB 比 df 的 209 GB 大很多，是因为它把 purgeable space（iCloud 占位符 + 系统可自动回收的缓存）也算进了”可用”。这 ~248 GB 的差额就是之前发现的那些 iCloud evicted 文件——系统知道在磁盘紧张时可以不重新下载它们，所以算作可调配空间。

顺手做的小事#

清理过程中还顺手做了几件事：

• blackAppleRegression 项目推到 GitHub（public）。Bad Apple!! 用递归模式匹配渲染的那个。视频从 mpeg4 转码成 H.264（QuickTime 播不了 mpeg4），上传了 YouTube 和 Bilibili
• dashboard 项目推到 GitHub（private）。飞凡 N1 盒子上跑的那个 kiosk 仪表盘
• 全局 CLAUDE.md 里加了 “prefer pnpm over npm” 的规则——pnpm 的 hardlink content-addressable store 能跨项目去重 node_modules

经验总结#

1. stat -f %z ≠ 实际占用。APFS + iCloud 环境下，逻辑大小和物理大小可以差出数百 GB。审计磁盘一定要用 du -sk（物理）或 stat -f %b（块数 × 512），不能用 stat -f %z。

2. iOS Simulator Runtimes 是隐形杀手。它们作为独立 APFS 容器存在，不在 ~/Library 里，du -sh ~ 扫不到。用 xcrun simctl runtime list 查看，xcrun simctl runtime delete 清理。

3. 删文件后空间不释放 → 检查 APFS 快照。tmutil deletelocalsnapshots 是解药。

4. Docker 日志不配 rotation 迟早爆盘。daemon.json 里加 "log-opts": {"max-size": "10m", "max-file": "7"}，然后必须重启 dockerd——已存在的容器不会自动应用新的 daemon defaults。

5. 删 App 要连带清数据。~/Library/Application Support/、~/Library/Containers/、~/Library/Group Containers/、~/Library/Caches/ 里经常有比 App 本体大好几倍的残留数据。