Mac 开发者磁盘空间告急：基于实测容量的安全清理顺序

先确认是真正的空间不足

开发机提示空间不足时，第一反应往往是删除一个看起来很大的文件夹。但 macOS 在“系统设置”>“通用”>“储存空间”里的分类可能需要时间重新计算，访达显示的容量也可能受到 APFS 可清除空间、快照和正在写入的临时文件影响。清理之前先用 df -h 看文件系统实际还能分配多少空间，再用 du -sh 看具体目录大小。两组数字回答的是不同问题：前者决定构建是否还能启动，后者告诉你应该从哪里找原因。

示例电脑在 2026 年 10 月 31 日的测量结果显示，系统宗卷所在的容器总容量约 494.4 GB，已用约 422 GB，可用约 5.4 GB。这个数字不是“开发者缓存总量”，也不是某个清理工具的估算，而是执行 diskutil info 和 df -h 得到的当时状态。开发工具会持续生成日志、编译中间产物和下载文件，所以文章中的数值只用于解释清理顺序，不能替代你在操作前后的测量。

如果可用空间已经低于 10 GB，先暂停大型归档、模拟器系统更新、视频导出和完整测试。它们可能在开始阶段额外写入几个 GB 的临时文件，导致构建中途出现“写入失败”、编译器被系统终止或 Xcode 结果包不完整。紧急阶段的目标不是一次性整理整台 Mac，而是先释放一块可验证、风险低、足以让系统恢复正常工作的空间。

1. 运行 df -h /，记录容器的可用空间；不要只看访达中某个文件夹的大小。
2. 用 du -sh 检查 ~/Library/Developer、~/.npm、~/.cache、~/Library/Caches 和当前仓库的 build 目录。
3. 先退出正在运行的 Xcode、模拟器、Docker、Node 开发服务器和会产生大型临时文件的测试任务。
4. 每完成一个类别就重新运行 df -h /，确认空间确实回来了，再进行下一类操作。

可用空间只剩几 GB 时，不要把“扫描中”误认为“已经安全”。先停止会继续写盘的任务，再保留一份删除前的目录大小记录。

这台开发机的空间账本说明了什么

把示例电脑的数据列出来后，问题会从“系统数据很大”变成几个可以分别验证的类别。~/Library/Developer 总计约 75 GB，其中 Xcode 目录约 67 GB、CoreSimulator 约 5.1 GB，另一款开发辅助工具的数据约 2.8 GB。Xcode 目录内部又分成 DerivedData 19 GB、iOS DeviceSupport 43 GB、两类符号备份合计约 4.6 GB、Archives 405 MB 等。最大的一项不是 Archives，而是为真机调试保留的支持文件和各个项目可重建的产物。

用户级缓存也很集中。~/.npm 约 4.7 GB，其中 _cacache 约 2.7 GB，_npx 约 2.0 GB；~/.cache 约 3.8 GB，其中 uv 约 1.8 GB、开发工具运行时约 1.6 GB。~/Library/Caches 约 9.1 GB，其中较大的有 Playwright 约 2.8 GB、开发工具缓存约 1.8 GB、go-build 约 1.1 GB、Google 约 1.0 GB。它们大多可以再生成或重新下载，但删除的后果是第一次使用对应工具会变慢，甚至需要联网。

仓库本身也要单独看。示例电脑上的一个开发工程约 19 GB，多个测试构建目录分别约 1.0–1.9 GB，分析数据目录约 7.8 GB，压力测试夹具约 2.0 GB。仓库里的构建产物和测试夹具要分开看，也不能和用户资料混在一起处理：构建产物可以按分支、版本和测试用途保留或归档，测试夹具则可能是调试样本或审计证据。

这份账本给出的优先级很明确：先评估 43 GB DeviceSupport 和 19 GB DerivedData，再处理 4.7 GB npm 和 3.8 GB 用户缓存，最后才决定是否动约 4.6 GB 的符号备份或测试数据。一个常见错误是先删除所有看起来叫 cache 的目录，却保留了真正占用几十 GB 的设备支持文件。名称相似不代表恢复成本相同。

第一轮：回收低风险、可再生的空间

第一轮清理的标准是“可以重新下载或重新构建，并且不会影响源代码、锁文件和发布凭证”。npm 的缓存可以先验证再清理，Go 的构建缓存可以用 go clean -cache 清除，之后构建时会自动重新生成；Homebrew 可以先用 brew cleanup -n 预览（全局运行 brew cleanup 时，它还会卸载已经没有软件需要的依赖），pnpm 可以用 pnpm store prune 删除没有任何项目引用的包。它们不应该和项目的 node_modules、Package.resolved、package-lock.json 或 go.mod 一起随意删除。

对于 npm，先运行 npm cache verify，确认缓存索引没有明显损坏。目标只是回收空间时，可以在确认当前没有安装任务后运行 npm cache clean --force；它会让后续 npm install 重新下载包，并不会删除当前项目已经存在的 node_modules。若只是某个一次性 npx 工具产生的缓存过大，先检查 ~/.npm/_npx 下的目录时间和用途，避免把仍在使用的临时环境删掉后又重复下载。

对于用户缓存目录，不能因为路径中出现 Caches 就对整个 ~/Library/Caches 执行递归强制删除。不同应用会把数据库、索引、登录状态或正在使用的临时文件放在相邻位置。更稳妥的做法是退出对应应用，按应用名检查大小，再用应用自身的清理入口；只有确认某个子目录确实是可再生缓存，才处理它。删除后重新打开应用，观察是否能够正常重建索引。

紧急空间不足时，先释放 5 到 10 GB 比追求一次清完 50 GB 更合理。系统恢复到有余量后，进程可以正常退出，废纸篓里的东西也有时间复核，开发者可以在不被迫中断的情况下继续测量。每次只动一个类别，还能知道清理哪一类才真正见效，也不会把之后构建变慢错怪到别的清理动作上。

第二轮：按项目处理 Xcode DerivedData

DerivedData 是当前机器上最适合按项目回收的类别之一。它保存编译产物、索引、模块缓存和日志，源代码与 Git 历史并不在这里。先退出 Xcode，然后打开 ~/Library/Developer/Xcode/DerivedData，按大小排序，找到长时间没有打开的项目。只删除一个项目文件夹的影响是下一次打开需要重新索引和完整编译；删除整个根目录则会让所有项目同时付出这个成本。

如果只是当前 scheme 的构建产物不一致，可以先在 Xcode 里使用 Product > Clean Build Folder。它的范围比删除项目的 DerivedData 更窄，不会动索引，也不影响其他项目。若问题表现为已经修复的代码仍显示错误、跳转定义错乱或模块缓存与 SDK 不匹配，再删除对应项目的 DerivedData。空间告急时，则应先用 du 找到真正大的旧项目，而不是在每次构建前例行清空。

删除前记下每个目录的大小和最后修改时间。Xcode 仍在运行时，索引器可能重新创建你刚移除的文件，或者某个构建任务正写入结果包。通过访达移到废纸篓比直接执行 rm -rf 更容易复核；确认新的构建、测试和代码索引都正常后，再清倒废纸篓。若必须在终端操作，也要把路径写成明确的单个项目目录，绝不使用未经检查的通配符。

DerivedData 回收之后，第一次构建变慢是预期结果，不是清理失败。建议在空间恢复后立即构建一个最常用的 scheme，让热缓存重新建立；再用 df -h 记录实际回收量。若刚删完又迅速涨回原来的大小，应检查是否在编译多个架构、生成大型 Swift 模块、运行 UI 测试或同时打开多个旧分支，而不是重复删除。

第三轮：检查 DeviceSupport、模拟器与发布符号

示例电脑的 iOS DeviceSupport 约 43 GB，是这次最值得审查的项目。它服务于连接真实 iPhone 或 iPad 时的调试，不等同于模拟器运行时，也不等同于已发布应用的 dSYM。可以保留当前测试设备需要的系统版本，先把很久没有连接过的旧版本记为候选。删除旧支持文件后，未来重新连接相应系统版本的设备时，Xcode 可能再次下载或准备它们，因此这里的收益是释放本地空间，代价是下次调试需要等待。

CoreSimulator/Devices 约 5.1 GB，当前还能看到 iOS 27.0 和 watchOS 26.5 的已关机设备，以及来自 iOS 26.4、26.5 的 unavailable 设备。已关机的设备不一定没用，可能包含测试数据库、登录状态和截图；unavailable 设备因为运行时已经不存在，通常更适合用 xcrun simctl delete unavailable 清理——设备里的 App 和数据会一并删除，所以清理前先导出仍需要的测试数据，并确认团队没有把某个模拟器 UUID 写进脚本。

Xcode Archives 只有约 405 MB，但符号备份目录合计超过 4 GB。Archives 里面可能有用于崩溃符号化和重新导出安装包的 dSYM，不能因为它们看起来像构建产物就直接删除。两类符号备份也不属于普通缓存：如果它们对应已分发版本或崩溃监控平台的符号上传记录，应先确认远端符号完整、备份可恢复，再按版本和 UUID 归档到外部存储。

那个约 2.8 GB 的开发辅助工具目录属于开发工具数据，处理前要检查当前是否仍在使用以及是否有本地运行时依赖。它与 iOS DeviceSupport 的恢复方式不同，不能只看“都在 Library/Developer”就使用同一条删除命令。开发者目录是分类账，不是一个可以整体清空的缓存桶。

项目产物与测试数据要按用途决定

示例电脑上的仓库约 19 GB，多个测试构建目录合计已经超过 5 GB，分析数据目录单独约 7.8 GB。这里不能套用“缓存都可以删”的规则。测试构建目录可能是最近一次验收证据，也可能只是旧运行产物；分析数据可能包含用于趋势报告的原始数据；压力测试夹具可能被测试脚本引用。先查看 README、脚本参数、文件修改时间和 Git 状态，确认它们是否可由命令重新生成。

对可以再生的版本产物，建议按版本建立清单，只保留当前发布候选、最近一次通过验收的结果和仍在调查的问题现场。对不能再生的测试样本，先压缩并移到外置磁盘或项目归档，再从工作区移除。不要在磁盘告急时顺手删除整个仓库的 .git、docs 或未经确认的 build 目录；仓库瘦身和磁盘急救是两个不同任务。

如果某个目录来自 CI 下载、模拟器录屏或性能追踪，先确认远端是否已有上传副本。大型 xcresult、Instruments trace 和视频文件通常比源代码更容易被忽略，但它们可能正是复现问题所需的证据。删除前给文件写入日期、版本号和用途，未来恢复时比重新猜测文件来源更省时间。

空间恢复后建立一个可持续预算

开发机不应该以“永远保持空闲”作为目标，而应该为不同类别设置预算。例如让系统至少保留 15% 的空闲空间，给活跃 Xcode 项目保留足够的 DerivedData 热缓存，给当前测试矩阵保留一到两套模拟器运行时，给 npm、uv、Go 和 Playwright 的共享缓存设定上限。预算的作用是触发测量，而不是让脚本无条件删除最近文件。

每周或每两周记录一次 df -h、~/Library/Developer、~/.npm、~/.cache 和 ~/Library/Caches 的大小变化。若一个类别在没有新增项目的情况下持续增长，就检查命名空间、下载失败产生的残留和重复版本；若只是跟随活跃开发增长，应该先决定是否值得付出重新下载的时间。对于团队机器，把清理命令和保留规则写进项目文档，避免每个人用不同的 rm -rf 习惯处理同一目录。

AskClean 的价值在于把目录按类别和恢复代价展示出来：Xcode DerivedData、模拟器、npm 等缓存、项目产物和来路不明的大文件夹，应该分别确认。扫描结果不能替你决定哪些归档属于发布证据，也不应该隐藏删除动作；用 AskClean 清理时，你确认的清理项会被直接永久删除，不经过废纸篓，所以核对要放在确认之前。最可靠的维护流程仍然是：先测量，一次只处理一类，处理完立刻验证构建，确认无误再继续下一类。

示例电脑 2026-10-31 容量实测

这些数字来自示例电脑当日的只读容量检查，用来说明优先级；每次清理前应重新测量。

容量会随构建、下载和系统清理实时变化；文章不把这些实测数字当作任何 Mac 的固定指标。

常见问题