الفرق بين Clean Build Folder وحذف DerivedData في Xcode
فريق AskClean · آخر تحديث 2026-11-02
يمسح Clean Build Folder نواتج بناء مخطط البناء (scheme) المفتوح لديك، أما حذف DerivedData فيعيد ضبط نطاق أوسع: نواتج البناء إضافة إلى الفهارس وذاكرة الوحدات المؤقتة والسجلات. إذا تعطل البناء فابدأ بـ Clean Build Folder، وإذا تلف الفهرس فاحذف مجلد DerivedData الخاص بذلك المشروع وحده، أما لاستعادة مساحة حقيقية فاحذف مجلدات DerivedData للمشاريع التي لم تعد تبنيها.
الفرق في النطاق لا في عمق التنظيف
يعمل الأمر Product > Clean Build Folder (Shift-Command-K) داخل المشروع والـ scheme المفتوحين حاليًا، فيتخلص من النواتج المترجمة والملفات الوسيطة لهذا السياق ليبدأ البناء التالي من المصدر. نطاقه مشروع واحد، ويُبقي عمدًا ما تكلف إعادة بنائه كثيرًا.
أما DerivedData فهو المجلد الأعلى المشترك بين كل المشاريع التي تستخدم الموقع الافتراضي، أي ~/Library/Developer/Xcode/DerivedData، وفيه مجلد فرعي لكل مشروع أو مساحة عمل فتحتها يومًا. حذف مجلد فرعي واحد يعيد ضبط ذلك المشروع وحده، أما حذف المجلد كله فيجعل كل مشاريعك تُعاد بناءً وفهرسةً عند فتحها التالي.
لذا فالوصف الدقيق للأمرين ليس «تنظيفًا خفيفًا» مقابل «تنظيف عميق». فـ Clean Build Folder ضيّق النطاق وقليل الكلفة، وحذف DerivedData واسع النطاق ويكلّفك الفهرس. واختيار أحدهما يتوقف كليًا على موضع الخلل: داخل نواتج البناء أم خارجها.
عندما يتعطل البناء، ابدأ بالأضيق
إذا ظهر الفشل مباشرة بعد تبديل الفرع أو تغيير إعدادات البناء أو تعديل ملفات الموارد، فأوقف التطبيق قيد التشغيل واستخدم Clean Build Folder أولًا. إنه أرخص إعادة ضبط متاحة، ويحافظ على الفهرس، ويعيدك إلى العمل بعد بناء واحد بدل بناء واحد تتبعه دقائق من الفهرسة.
وانتقل إلى حذف مجلد DerivedData الخاص بذلك المشروع عندما لا تتعلق الأعراض بنواتج البناء فعلًا: أخطاء يعرضها Xcode في شيفرة أصلحتها بالفعل، أو انتقال إلى التعريف ينتهي في المكان الخطأ، أو إكمال تلقائي توقف عن فهم الأنواع التي عرّفتها. هذه أعراض في الفهرس، وClean Build Folder لا يمس الفهرس.
وهناك حالة محددة تستحق المعرفة، لأنها السبب المعتاد في أن تتحول عبارة «نظّفت ولم ينفع» إلى «حذفت DerivedData فنفع»: ذاكرة الوحدات المترجمة مسبقًا (ModuleCache.noindex) تقع في جذر DerivedData، لا داخل المجلد الفرعي لأي مشروع، فلا يصل إليها Clean Build Folder أبدًا. وعندما تتقادم هذه الذاكرة بعد تغيير SDK أو سلسلة الأدوات، فلا يزيل الخطأ إلا حذفها.
لا يُصلح أي من الإجراءين خللًا حقيقيًا في شيفرتك أو اعتمادياتك. فإذا بقي الخطأ نفسه بعد بناء نظيف، فتوقف عن التنظيف واقرأ رسالة المترجم؛ فالسبب في إعدادات المشروع أو Package.resolved أو SDK المحدد أو الشيفرة نفسها.
لا يُعد أي منهما خطة لتنظيف القرص
Clean Build Folder أداة تشخيص تحرر بعض البايتات عرضًا. قد يعيد مساحة للمشروع الحالي، لكن نواتج بناء كل المشاريع الأخرى وكل الفهارس وذاكرة الوحدات تبقى في مكانها تمامًا، فتشغيله لاستعادة المساحة استخدام للأداة في غير موضعها.
وإن كانت المساحة هي الهدف الفعلي، فاسلك الطريق المعاكس: قِس المجلدات الفرعية في DerivedData أولًا، ثم احذف مجلدات المشاريع التي لم تفتحها منذ أشهر. فهناك تكمن عادةً عشرات الغيغابايتات: نسخ مستنسخة بنيتها مرة ولم تعد إليها.
لا تبدأ بـ rm -rf. يتيح لك Finder نقل المجلدات المحددة إلى سلة المهملات، فتبقى قابلة للاستعادة حتى تفرغها، وهذا الفرق مهم أول مرة تحذف فيها مجلد مشروع يتبين أنه قيد البناء في تلك اللحظة. والوحدة الطرفية مفيدة للأتمتة، لكن فقط بعد أن تتأكد من المسار الدقيق.
تحقق من النتيجة بدل الوثوق برقم
سجّل حجم DerivedData قبل أي خطوة، وطبّق خيارًا واحدًا فقط من الخيارين، ثم قِس مجددًا. بعد Clean Build Folder ابنِ الـ scheme الحالي، وبعد حذف مجلد DerivedData افتح Xcode وانتظر حتى ينتهي البناء الأول وجولة الفهرسة.
بهذا الترتيب تفصل المساحة التي استعدتها عن الثمن الذي دفعته لاستعادتها. ولا يوجد رقم عام يمكن توقعه: فالنتيجة تتوقف على عدد المشاريع وتكوينات البناء والمعماريات التي بُنيت على جهاز Mac ذاك تحديدًا.
أيهما تختار
| الحالة | ما تفعله | كلفة الاستعادة |
|---|---|---|
| فشل البناء في الـ scheme الحالي | Product > Clean Build Folder | إعادة بناء واحدة لهذا المشروع، وتبقى فهارس كل المشاريع محفوظة. |
| أخطاء قديمة وانتقال معطّل إلى التعريف | ~/Library/Developer/Xcode/DerivedData/<project> | إعادة بناء كاملة وإعادة فهرسة، لهذا المشروع وحده. |
| أخطاء تبقى بعد Clean Build Folder إثر تغيير SDK | ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex | تُعاد ترجمة الوحدات في البناء التالي، ولا يصل إليها Clean Build Folder. |
| تحتاج فعلًا إلى مساحة قرص | ~/Library/Developer/Xcode/DerivedData | احذف المجلدات الفرعية الكبيرة القديمة، ويُعاد بناء تلك المشاريع عند فتحها التالي. |
| بيئات تشغيل المحاكي القديمة | Xcode Settings > Components | فئة منفصلة تمامًا لا يمسها أي من الإجراءين. |
يصف هذا الجدول النطاق، لا عددًا موعودًا من الغيغابايتات. قِس جهاز Mac لديك قبل الإجراء وبعده.
الأسئلة الشائعة
هل يحذف Clean Build Folder مجلد DerivedData؟
لا. فهو يمسح نواتج البناء للمشروع والـ scheme المفتوحين لديك، ولا يعادل حذف مجلد DerivedData المشترك الذي يضم أيضًا الفهارس وذاكرة الوحدات والسجلات لكل المشاريع.
هل حذف مجلد DerivedData لمشروع واحد آمن؟
نعم. كل ما فيه مشتق من شيفرتك المصدرية ويعيد Xcode إنشاءه، ولا تُمس شيفرتك ولا سجل git. الكلفة الوحيدة أن أول بناء بعده يكون بناءً كاملًا تتبعه جولة فهرسة.
هل يجب أن أُنهي Xcode أولًا؟
عند حذف DerivedData يدويًا، نعم؛ فهذا يمنع المفهرس من الإمساك بالملفات أو إعادة إنشائها أثناء حذفها. أما أمر Clean Build Folder المدمج فلا، لأن Xcode هو الذي ينفذه بنفسه.
لماذا بقي الخطأ بعد التنظيف؟
على الأرجح لم يكن السبب في الذاكرة المؤقتة أصلًا. افحص رسالة المترجم وإعدادات الـ scheme وإصدارات الاعتماديات وPackage.resolved وSDK المحدد، وما الذي تغيّر فعلًا في الفرع الحالي.
لم يُجدِ Clean Build Folder نفعًا لكن حذف DerivedData أصلح المشكلة. لماذا؟
السبب في الغالب ذاكرة الوحدات المترجمة مسبقًا: يقع ModuleCache.noindex في جذر DerivedData لا داخل مجلد فرعي لمشروع، فلا يصل إليه Clean Build Folder، بينما يصل إليه حذف DerivedData.
المصادر