那 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 自己的工具也得先完整拷一遍才肯帮你处理。 我们也反过来验证了一下：在 `/tmp` 放一个普通的 9 GB 文件，只剩 14.6 GB 空余，同样的预检照样通过。同一个卷，大小差不多，只是没有 SIP 保护，守护进程就没意见。 更要紧的是，被拒绝的 `runtime add` 其实有副作用。守护进程判定磁盘太满的时候，已经把镜像拷进了自己的仓库，还注册成了一个 `Unusable` 运行时，而且这两样都不会清掉。三次被拒之后，`/Library/Developer/CoreSimulator/Cryptex/Images/` 里多了三份 8.38 GB 的拷贝，`Inbox` 里还有一份 9 GB。 加起来 34 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 差得远。注册记录没了，bundle 也卸载了，但 8.4 GB 的 `.asset` 还在原地。`simctl runtime delete` 从来不删它当初安装时用的那个 MobileAsset。Apple 还专门提供了一个 `--keep-asset` 开关，看起来像是默认会删 asset，可在 Cryptex 支撑的运行时上，加不加这个开关都一样。 所以我们当时认为，要拿回这块空间只剩一个办法：用 `runtime add --move` 把镜像从受保护的仓库里迁出来。但这条路没法克隆，需要空闲空间有「镜像大小 + 大约十分之一的磁盘容量」。一块 494 GB 的盘上有 16.9 GB 已经没用的模拟器，你就得先腾出大约 58 GB。 *一周后的更新（我们腾出了那 58 GB，真的试了一次）：* 这条路也走不通。守护进程认领了自己那份副本，然后打出「--move was specified but unable to remove original file: Operation not permitted」。也就是说，Apple 自己带特权的服务，和你一样删不掉封印资产库里的文件。而且每试一次，CoreSimulator 的 `Images/Inbox` 里就会多一份 8 GB 的暂存副本，我们试过的办法都删不掉它：`simctl` 不行，输入管理员密码用 root 跑 `rm` 也不行。所以放在 Apple 资产库里的运行时，没有任何程序能把那部分空间拿回来。现在唯一还能删它们的地方是 Xcode 自己的 设置 ▸ Components，已登记的运行时旁边有个移除按钮。 回头看，空间那笔账一直算得没错。我们先是把标签贴错了，后来又把路选错了。 测的过程中还发现了两个问题。删掉一个运行时再重新扫描，它又回来了：我们自己的修复步骤用一个新 UUID 把刚没了父级的 asset 重新认领了，等于把删除撤销了。另外，一次其实成功了的删除被报成了失败，因为我们只等了 15 秒，CoreSimulator 还没重新发布注册表。这两个都修好了。我们也是开始去测文件系统、不再只信注册表之后，才发现这两个 bug 的。 还有一个 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 又加到了本来就包含它的分类上。 磁盘工具都会按路径去对两份测量结果，只要不经过 firmlink 表来比较，就会有这个 bug。这个问题在 APFS 之前就有：两个不一样的路径可能是同一个文件，所以要比设备号和 inode，不能只比字符串。 ### 从来不存在的 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 上这样一跑，那两个「孤儿」镜像就被正确识别成了两个已安装运行时的底层镜像。Mint 把它们放在「保留」里，并写明唯一能删掉它们的地方是 Xcode 的 Components 面板。要是给一个删除按钮，只会释放 21 MB，剩下的还会报成「什么也没移除」。Mint 现在根本不走 `runtime add --move` 这条路，所以不会再留下 8 GB 的暂存副本。CoreSimulator 已经标成 `Unusable` 的副本按 UUID 删除；留在 `Inbox` 里的暂存副本，会用管理员密码试一次。如果一次删除在用户输入管理员密码之后仍然被拒绝，Mint 会记下来，在文件或系统有变化之前不再显示这一行。 说实话，这些坑都不算 macOS 的 bug。封印的系统卷、firmlink、写时复制克隆、延迟回收、会自己修复的运行时登记表，设计上都没问题，平时用 Mac 也完全感觉不到。只有当一个程序要告诉你空间去哪了，它们才会出问题，因为每一个都会让「目录占多大」和「删掉能拿回多少」对不上。 做磁盘清理工具最省事的办法，是遍历目录树、按大小排序，然后在大的东西旁边放个勾选框。碰上上面这些坑，这种做法显示的数字都会比实际能拿回的大，用户要等点了删除才会发现。 让我们付出代价最大的两次，都跟测量误差无关。第一次是登记表说「没有任何东西引用它」，我们就信了，没先确认它是不是已经数完了。第二次是注册表显示删除成功，我们就以为命令起作用了，没去看磁盘上到底有没有字节被释放。 --- *这些数据都是 2026 年 8 月在一台开发者 Mac 上用 Mint 的只读扫描 hook 测的，你也可以在自己的机器上复现。想看 coding agent 会留下什么，可以读另一篇：[你的 Coding Agent 正在吃掉你的硬盘](/build-journey/agents-are-not-a-black-box)。*

测量方法