那 16.9 GB 根本不是垃圾

我们上线了一个检测器，它在一台开发者的 Mac 上找到了 16.9 GB「已废弃的 iOS 模拟器运行时」。它很笃定，很具体，连版本号都报得出来。 它也是错的。那些文件是两个**仍然装着的**模拟器的底层镜像。 这篇文章讲的是一个磁盘工具怎么把自己说服到那一步——因为这条链上的每一环都是陷阱，而其中三个此刻还在悄悄吃掉别人的空间。下面每个数字都是 2026 年 8 月 19 到 21 日在同一台 Mac 上实测的，你可以全部复现。 :::disk-traps-ledger ### macOS 不让你删的那堆垃圾 Xcode 每次下载 iOS 模拟器，系统镜像都会落进 Apple 的资产仓库：`/System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/ .asset`，每个 8–9 GB。运行模拟器的服务 CoreSimulator 维护着一份它认识的运行时登记表，`xcrun simctl runtime list` 就能打印出来。 那天早上，登记表里只有一个运行时——iOS 26.5——而目录里有三个。另外两个是 iOS 18.2 和 iOS 18.4，8.4 GB 和 8.5 GB，2025 年初下载的。 于是：两个大镜像，登记表里没有任何东西指向它们。这是「孤儿」的教科书定义，也正是我们的扫描器给出的结论。 第一个意外是，你根本删不掉它们： ``` $ ls -lO /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/ drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Feb 4 2025 3ee34d77….asset drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Apr 8 2025 6fb1e5fe….asset ``` `restricted` 是系统完整性保护（SIP）的标志：这个目录对所有人关闭，`sudo rm` 也不例外。网上针对这个问题的标准建议是「关掉 SIP、重启、删除、再打开 SIP」。我们不会把这种建议交给任何用户。 **能**删掉它们的，是 Apple 自己的运行时服务。你请它把镜像重新认领回登记表——`simctl runtime add --move`——然后按 UUID 删除。守护进程会用自己的权限亲手删掉文件，不需要密码。 ### 一次被拒，代价 8 GB 认领被拒绝了： ``` $ xcrun simctl runtime add …/092-10337-196.dmg --move SimDiskImageError code=14: Cannot copy the image because the disk is almost full ``` 当时空余 24.7 GB，镜像 8.4 GB。守护进程的日志全被打了码，所以我们直接去翻它的二进制： ``` $ strings …/CoreSimulator.framework/…/simdiskimaged minFreeSpace = %llu Because source is on the same volume as inbox and clones are supported will allow a lower free space limit ``` 这句话就是全部答案。当服务能对源文件做 APFS 克隆——写时复制，瞬间完成，零额外字节——它几乎不需要空余空间。当它做不到克隆，就退回逐字节的完整拷贝，并要求「镜像大小 + 一大块预留」。 而它无法从受 SIP 保护的资产仓库里克隆。所以：你唯一不被允许删除的那个目录，恰好也是 Apple 自己的工具必须先完整拷贝一遍才肯帮你的那个目录。 我们从反面验证了这个机制：把一个普通的 9 GB 文件放在 `/tmp`，只剩 14.6 GB 空余时，同一道预检轻松通过。同一个卷、同样的大小、没有 SIP 保护——它一声不吭。 然后是真正要紧的部分。**被拒绝的 `runtime add` 不是无副作用的。** 在它判定磁盘太满之前，守护进程**已经**把镜像拷进了自己的仓库、注册成了一个 `Unusable` 运行时，然后把两者都留在原地。三次拒绝，在 `/Library/Developer/CoreSimulator/Cryptex/Images/` 留下三份 8.38 GB 的拷贝，外加 `Inbox` 里一份 9 GB。 三十四 GB 的残留，全部由「报告失败」的操作产生。没有任何工具会列出它——对你的主目录跑 `du` 永远看不到，而拥有它的那个运行时也不会出现在 `simctl runtime list` 的普通输出里。 ### 那些垃圾并不是垃圾 到这一步，诚实的总结是：16.9 GB 谁也删不掉，而且那条认领路线每失败一次就让情况更糟。 这个总结是错的，一条命令就能说明原因。 `xcrun simctl runtime scan-and-mount` 是 Apple 自己的修复命令。它让 CoreSimulator 遍历自己的存储、把丢失记录的东西重新认领回来。耗时约十分之一秒。跑完之后，登记表变成了这样： ``` $ xcrun simctl runtime list iOS 18.2 (22C150) - 87410283-… (Ready) iOS 26.5 (23F77) - 8E56E104-… (Ready) iOS 18.4 (22E238) - 10B15C7F-… (Ready) Total Disk Images: 3 (24.2G) ``` 一个运行时变成了三个。而 iOS 18.4 的完整 JSON 记录里，有一个摘要输出从不显示的字段： ``` parentImagePath = /System/Library/AssetsV2/…/6fb1e5fe….asset/AssetData/090-44150-318.dmg ``` 那个「孤立」的 asset，是一个已安装、可运行的运行时的**父镜像**。CoreSimulator 只是弄丢了那两个装着 iOS 18.2 和 18.4 的 Cryptex bundle 的注册记录；在记录缺失的那段时间里，机器上没有任何东西声称拥有这些 asset。字节从未改变，改变的是它们的身份。 清理随后变得毫无代价。对那三个 `Unusable` 残留执行 `simctl runtime delete `，34 GB 全部释放——不要密码，不要暂存空间，连 `Inbox` 都顺手清空了。那两个 18.x 运行时现在出现在我们的扫描结果里，成了它们本来的样子：一个没有任何模拟器在用，一个被更新的版本取代，都可以按 UUID 直接删除。 ### 然后我们又错了一次 删掉它们，几乎什么也不会释放。 我们用自己的执行器跑了一遍并测量：删除 iOS 18.2 运行时，实际拿回 **21 MB**。不是 8.4 GB，是 21 MB。注册记录消失了，bundle 卸载了，而 8.4 GB 的 `.asset` 原封不动待在原地。`simctl runtime delete` 从不删除它当初安装自的那个 MobileAsset。Apple 甚至提供了一个 `--keep-asset` 开关，强烈暗示默认行为是相反的——而在 Cryptex 支撑的运行时上，加不加它毫无区别。 所以这块空间终究只有一条路可走：`runtime add --move`，把镜像从受保护的仓库里迁出来——而它无法克隆，于是要求「镜像大小 + 约十分之一的磁盘容量」是空闲的。在一块 494 GB 的盘上、面对 16.9 GB 的死模拟器，这意味着你得先腾出大约 58 GB。 鸡和蛋从头到尾都是真的。错的是标签，不是那道算术。 测量过程里还掉出来两件事。删掉一个运行时再重新扫描，它**又回来了**——我们自己的修复步骤把刚刚失去父级的 asset 用一个新 UUID 重新认领了，等于撤销了这次删除。以及，一次其实已经成功的删除被报成了失败，因为 CoreSimulator 没能在我们等待的 15 秒窗口内重新发布注册表。两者都已修复；而它们之所以此前不存在，只是因为我们终于去测量文件系统，而不是注册表。 最后一个 Apple 的怪癖，送给所有自己写清理逻辑的人：`simctl runtime delete --notUsedSinceDays 90` 在这台机器上什么也没匹配到——尽管两个 18.x 运行时的 `lastUsedAt` 都是 `null`。Apple 自己的「删掉你没用过的」过滤器，恰好跳过了你**从来没用过**的那些。 ### 一个目录，两个名字 在做「磁盘都去哪了」那张图时，一个内部检查开始报警：Developer 分类下各子项之和，比分类本身**多**出 18.1 GB。这本不可能——每个子项都是在父项内部测出来的。它报了 502 次，多出来的永远是 18.1 GB。 原因是 firmlink。从 Catalina 开始，macOS 把系统放在一个封印的只读卷上、把你的数据放在另一个卷上，再缝合起来让文件系统看上去像一棵树。于是有些路径有了两种写法，而它们字面上就是同一个目录： ``` $ stat -f '%d %i %N' /System/Library/AssetsV2 /System/Volumes/Data/System/Library/AssetsV2 16777233 210916113 /System/Library/AssetsV2 16777233 210916113 /System/Volumes/Data/System/Library/AssetsV2 ``` 同一个设备、同一个 inode、两个名字。我们的全盘测量用一种写法记下了模拟器目录，扫描器用另一种写法报告了运行时，字符串比较说这是两个地方，于是 18.1 GB 被叠加到了一个已经包含它的分类上。 任何按路径对账两份测量结果的工具——所有磁盘工具都这么干——都有这个 bug，除非它通过 firmlink 表来比较。这个教训比 APFS 古老得多：两个不同的字符串，仍然可以是同一个文件。 ### 从来不存在的 46.7 GB 对 Chrome 的更新残留跑一下 `du`，它会报出 34 个 `*.code_sign_clone` 目录、共 46.7 GB。把它们全删掉，空余空间变化为零。 它们是 APFS 克隆。Chrome 在代码签名时给自己的程序包做写时复制快照，克隆与原件共享每一个数据块，直到其中一方被修改——而这永远不会发生。`du` 报的是它看到的逻辑大小，而它看到的是一个 1.4 GB 的应用，乘以 34。 按 `du` 排序的清理工具会把这些排在榜首，让你「释放」46.7 GB，然后留你盯着一个纹丝不动的数字。我们改为测量实际分配的数据块，并在总览里完全跳过克隆目录——承诺 46.7 GB 却什么都不交付，比根本不提它们更糟。 ### 晚到一秒的删除 最后一个很小，而且就在我们写这篇文章的当天咬了我们一口。 我们清理后的回执，报告的不是被删掉的东西有多大，而是在卷上**观测到**的空余空间变化——在最后一个文件消失后立即采样，因为这是用户唯一能拿去和访达对照的数字。几个月来一直没问题。 然后有人删了两个 9 GB 的目录，回执写着 `freedBytes: 0`。文件确实没了，历史记录写着永久删除 17.5 GB，而 375 毫秒后读到的卷空余空间，一动没动。 APFS 对大目录的数据块回收是异步的。几百 MB 几乎是瞬时的；几十 GB 要好几秒，在这个窗口里采样什么也看不到。窗口顶部那个只读一次的大标题也停在原地——在用户眼里，这和「删除没起作用」一模一样。 修法很无趣：处理的字节越多就采样越久，观测到的变化不再增长时停止，并在任何释放空间的动作之后按一个短节奏重读标题数字——不管是哪个按钮触发的。 ### 我们改了什么 检测器没有被删掉；它只是不再被允许凭一份自己没核实过的登记表去指控任何东西。在 Mint 把任何模拟器存储称为「孤儿」之前，它现在会先请 CoreSimulator 重新认领自己的存储，再重读登记表。在这台 Mac 上，这把两个「删不掉的残留运行时镜像」变成了两行普通的、可以按 UUID 一键删除、不需要密码的条目。而当认领路线真的执行、Apple 拒绝了它时，Mint 现在会清理掉自己产生的暂存残留，而不是每次留下 8 GB。 这些陷阱都不是 macOS 的 bug。封印的系统卷、firmlink、写时复制克隆、延迟回收、会自我修复的运行时登记表，全都是好的工程，而且在你只是使用这台机器时全都不可见。它们只会成为一种程序的麻烦：声称知道你的空间去了哪里的程序——因为每一条都在「一个目录有多重」和「删掉它能还回来多少」之间撕开一道缝。 做磁盘清理工具的便宜做法，是遍历目录树、按大小排序、在大东西旁边放复选框。上面每一个陷阱，都是这种做法产出一个「对用户有利的错误数字」的方式——直到他们点下去的那一刻。 而代价最大的那两个，根本不是测量误差。一个是我们相信了一个答案——「没有任何东西引用它」——却没有先问一句：给出这个答案的东西，有没有数完。另一个是我们以为一条命令干完了活，因为注册表同意了——却没有去看，究竟有没有一个字节真的动过。 --- *所有测量均于 2026 年 8 月在一台开发者 Mac 上用 Mint 的只读扫描 hook 完成，可以在你的机器上复现。关于 coding agent 留下了什么的姊妹篇：[你的 Coding Agent 正在吃掉你的硬盘](/build-journey/agents-are-not-a-black-box)。*