Clean Build Folder Xcode lwn memadam DerivedData
Pasukan AskClean · Dikemas kini 2026-11-02
Clean Build Folder mengosongkan produk binaan bagi skema yang sedang anda buka. Memadam DerivedData menetapkan semula skop yang lebih luas: produk binaan serta indeks, cache modul dan log. Jika binaan rosak, mulakan dengan Clean Build Folder; jika indeks rosak, padam folder DerivedData bagi projek itu sahaja; untuk mendapatkan semula ruang cakera sebenar, padam folder DerivedData bagi projek yang tidak lagi anda bina.
Perbezaannya ialah skop, bukan tahap kebersihan
Product > Clean Build Folder (Shift-Command-K) berfungsi dalam projek dan skema yang sedang anda buka. Perintah ini membuang produk terkompil dan fail perantaraan bagi konteks itu supaya binaan seterusnya bermula semula daripada kod sumber. Skopnya terhad kepada satu projek, dan ia sengaja mengekalkan data yang mahal untuk dibina semula.
DerivedData ialah direktori peringkat atas yang dikongsi oleh setiap projek yang menggunakan lokasi lalai — ~/Library/Developer/Xcode/DerivedData, dengan satu subfolder bagi setiap projek atau ruang kerja yang pernah anda buka. Memadam satu subfolder hanya menetapkan semula projek itu. Memadam seluruh direktori pula menyebabkan setiap projek anda dibina dan diindeks semula apabila dibuka nanti.
Jadi, cara yang jujur untuk membandingkan kedua-duanya bukanlah “pembersihan ringan” lawan “pembersihan menyeluruh”. Clean Build Folder sempit dan murah; memadam DerivedData luas skopnya dan menyebabkan anda kehilangan indeks. Pilihan yang betul bergantung sepenuhnya pada sama ada perkara yang rosak itu berada di dalam produk binaan atau di luarnya.
Apabila binaan rosak, mulakan dengan skop yang sempit
Jika kegagalan muncul sejurus selepas anda bertukar cawangan, mengubah konfigurasi binaan atau menyunting fail resource, hentikan aplikasi yang sedang berjalan dan gunakan Clean Build Folder dahulu. Inilah cara set semula yang paling murah: indeks dikekalkan, dan anda boleh kembali bekerja selepas satu binaan, bukannya satu binaan ditambah beberapa minit pengindeksan.
Beralih kepada memadam folder DerivedData projek itu apabila simptomnya sebenarnya tidak berkaitan dengan produk binaan: Xcode memaparkan ralat bagi kod yang sudah anda betulkan, jump to definition membawa anda ke tempat yang salah, atau pelengkapan kod tidak lagi mengenali jenis (type) yang anda takrifkan sendiri. Itu simptom indeks, dan Clean Build Folder tidak menyentuh indeks.
Ada satu kes khusus yang patut diketahui, kerana inilah sebab biasa “sudah buat clean tetapi tidak membantu” bertukar menjadi “padam DerivedData dan masalah selesai”: cache modul prakompil (ModuleCache.noindex) terletak di akar DerivedData, bukan di dalam subfolder mana-mana projek. Clean Build Folder tidak pernah sampai ke situ. Apabila cache modul menjadi lapuk selepas perubahan SDK atau toolchain, hanya membuangnya yang akan menghilangkan ralat itu.
Kedua-dua perintah tidak membaiki pepijat sebenar dalam kod sumber atau kebergantungan anda. Jika ralat yang sama masih muncul selepas binaan bersih, berhenti membersihkan dan baca mesej pengkompil — puncanya ada pada tetapan projek, Package.resolved, SDK yang dipilih atau kod itu sendiri.
Kedua-duanya bukan strategi pembersihan cakera
Clean Build Folder ialah alat diagnostik yang kebetulan membebaskan sedikit ruang. Ia boleh mengembalikan ruang bagi projek semasa, tetapi produk binaan setiap projek lain, semua indeks dan cache modul kekal di tempatnya. Menjalankannya untuk mendapatkan semula ruang cakera bermakna anda mengukur perkara yang salah.
Jika ruang ialah matlamat sebenar, lakukan sebaliknya: ukur subfolder DerivedData dahulu, kemudian padam projek yang sudah berbulan-bulan tidak dibuka. Di situlah biasanya berpuluh-puluh gigabait berada — klon sekali guna yang pernah anda bina sekali lalu tidak dibuka lagi.
Jangan mulakan dengan rm -rf. Finder membolehkan anda mengalihkan folder yang dipilih ke Sampah, yang masih boleh dipulihkan sehingga anda mengosongkannya, dan perbezaan itu penting apabila anda pertama kali memadam folder projek yang rupa-rupanya sedang dibina. Terminal berguna untuk automasi, tetapi hanya selepas anda mengesahkan laluan yang tepat.
Semak hasilnya, jangan bergantung pada angka
Catat saiz DerivedData sebelum melakukan apa-apa, gunakan hanya salah satu daripada dua pilihan itu, kemudian ukur semula. Selepas Clean Build Folder, bina skema semasa. Selepas memadam folder DerivedData, buka Xcode dan tunggu sehingga binaan pertama dan proses pengindeksan selesai.
Dengan urutan ini, anda dapat membezakan ruang yang diperoleh semula daripada kos yang dibayar untuk mendapatkannya. Tiada angka umum yang boleh dijangkakan: hasilnya bergantung pada bilangan projek, konfigurasi dan seni bina yang pernah dibina pada Mac itu.
Pilihan mengikut situasi
| Situasi | Tindakan | Kos pemulihan |
|---|---|---|
| Binaan gagal pada skema semasa | Product > Clean Build Folder | Satu binaan semula bagi projek ini. Indeks semua projek dikekalkan. |
| Ralat lapuk, jump to definition tidak tepat | ~/Library/Developer/Xcode/DerivedData/<project> | Binaan semula penuh serta pengindeksan semula, bagi projek itu sahaja. |
| Ralat kekal selepas Clean Build Folder berikutan perubahan SDK | ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex | Modul dikompil semula pada binaan seterusnya. Tidak dapat dicapai oleh Clean Build Folder. |
| Anda benar-benar memerlukan ruang cakera | ~/Library/Developer/Xcode/DerivedData | Padam subfolder lapuk yang besar; projek berkenaan dibina semula apabila dibuka nanti. |
| Runtime simulator lama | Xcode Settings > Components | Kategori yang berasingan sama sekali. Kedua-dua perintah tidak menyentuhnya. |
Jadual ini menerangkan skop, bukan jumlah gigabait yang dijanjikan. Ukur Mac anda sendiri sebelum dan selepas.
Soalan lazim
Adakah Clean Build Folder memadam DerivedData?
Tidak. Ia mengosongkan produk binaan bagi projek dan skema yang sedang dibuka. Ia tidak sama dengan memadam direktori DerivedData yang dikongsi, yang turut menyimpan indeks, cache modul dan log bagi setiap projek.
Adakah selamat memadam folder DerivedData bagi satu projek?
Ya. Segala isinya dijana daripada kod sumber anda, dan Xcode akan menjananya semula. Kod dan sejarah git anda tidak disentuh. Satu-satunya kos ialah binaan pertama selepas itu menjadi binaan penuh, diikuti proses pengindeksan.
Perlukah saya keluar daripada Xcode dahulu?
Untuk memadam DerivedData secara manual, ya — ini mengelakkan pengindeks memegang atau mencipta semula fail semasa anda membuangnya. Untuk perintah Clean Build Folder terbina dalam, tidak perlu; Xcode sendiri yang melakukannya.
Mengapa ralat masih ada selepas pembersihan?
Kemungkinan besar puncanya memang bukan cache. Semak mesej pengkompil, tetapan skema, versi kebergantungan, Package.resolved, SDK yang dipilih dan perkara yang sebenarnya berubah pada cawangan semasa anda.
Clean Build Folder tidak membantu, tetapi memadam DerivedData berjaya. Mengapa?
Biasanya kerana cache modul prakompil. ModuleCache.noindex terletak di akar DerivedData, bukan di dalam subfolder projek, jadi Clean Build Folder tidak dapat mencapainya — memadam DerivedData pula turut membuangnya.
Sumber