Xcode Clean Build Folder 和删除 DerivedData 有什么区别？

区别在于范围，而不是清得彻不彻底

Product > Clean Build Folder（Shift-Command-K）只作用于你当前打开的项目和 scheme。它会丢弃这个范围内已编译的产物和中间文件，让下一次构建从源代码重新开始。它的范围仅限一个项目，而且会刻意保留那些重建成本高的东西。

DerivedData 则是所有使用默认位置的项目共用的顶层目录——~/Library/Developer/Xcode/DerivedData，你打开过的每个项目或工作区各有一个子文件夹。删除其中一个子文件夹，只会重置那一个项目；删除整个目录，你的所有项目下次打开时都要重新构建、重建索引。

所以，这两者的区别并不是“轻度清理”和“深度清理”。Clean Build Folder 范围窄、代价小；删除 DerivedData 范围广，还要搭上索引。该用哪个，完全取决于出问题的东西是在构建产物之内，还是在构建产物之外。

构建出错时，先从小范围开始

如果问题是在你切换分支、修改构建配置或编辑资源文件之后立刻出现的，先停止正在运行的 App，再执行 Clean Build Folder。这是代价最小的重置方式：它会保留索引，构建一次就能回到工作状态，不用再额外等几分钟重建索引。

如果症状其实和构建产物无关，就升级为删除该项目的 DerivedData 文件夹：比如 Xcode 对已经修好的代码仍然报错、跳转到定义跳到了错误的位置、代码补全突然认不出你自己定义的类型。这些都是索引出了问题，而 Clean Build Folder 不会碰索引。

有一种情况特别值得了解，因为“清理了也没用”最后变成“删了 DerivedData 才好”，通常就是它：预编译模块缓存（ModuleCache.noindex）位于 DerivedData 的根目录，而不在任何项目的子文件夹里，Clean Build Folder 根本碰不到它。SDK 或工具链变更后模块缓存过期时，只有删掉它才能消除错误。

这两种做法都修不了源代码或依赖里真正的 bug。如果全新构建之后同样的错误依然存在，就别再清理了，仔细读一读编译器的报错——原因在项目设置、Package.resolved、所选的 SDK，或者代码本身。

两者都不是腾磁盘空间的办法

Clean Build Folder 是排查问题的工具，只是顺便能释放一点空间。它能腾出当前项目的空间，但其他项目的构建产物、所有索引和模块缓存都原封不动。拿它来回收磁盘空间，是找错了对象。

如果真正的目标是空间，就反过来做：先测量 DerivedData 下各个子文件夹的大小，再删除那些几个月没打开过的项目。几十 GB 的占用通常就藏在这里——构建过一次就再也没回去过的临时克隆。

不要一上来就用 rm -rf。在访达里可以把选中的文件夹移到废纸篓，清倒废纸篓之前都还能恢复；等你第一次误删了一个其实正在构建的项目的文件夹，就会明白这个区别有多重要。终端适合用来做自动化，但前提是你已经确认了准确的路径。

核对结果，不要只相信某个数字

动手之前先记下 DerivedData 的大小，两种做法只选一种执行，然后再测量一次。用了 Clean Build Folder 之后，构建一次当前的 scheme；删除 DerivedData 文件夹之后，打开 Xcode，等第一次构建和索引都跑完。

按这个顺序做，才能把腾出的空间和为此付出的代价分开看清楚。没有放之四海而皆准的数字：结果取决于这台 Mac 上构建过多少项目、配置和架构。

该用哪一个

此表说明的是作用范围，不承诺能腾出多少 GB。请在操作前后测量你自己的 Mac。

常见问题