Was ist ~/Library/Caches auf dem Mac und was darf weg?

Ein echter Cache lässt sich neu aufbauen, aber ein Ordner mit dem Namen Cache ist nicht automatisch sicher zu löschen. Apps mischen manchmal Offline-Downloads, Sitzungszustand, Indizes und noch nicht synchronisierte Arbeit neben entsorgbaren Dateien. Die nützliche Fähigkeit besteht nicht darin, eine Liste von Pfaden auswendig zu lernen, sondern den Eigentümer, die Rebuild-Quelle und die Folgen eines Cache-Misses zu erkennen.

Hier erfahren Sie, welche Arten es gibt, wo sie liegen und was Sie vor dem Leeren prüfen sollten.

Apples Hinweise zu Library-Verzeichnissen definieren Cache als neu erzeugbare Daten, von deren Fortbestand eine App nicht abhängen darf. Application Support hat einen anderen Wiederherstellungsvertrag.

~/Library/Caches und /Library/Caches haben unterschiedliche Geltungsbereiche

• ~/Library/Caches enthält nutzerbezogene App-Caches, die größte alltägliche Gruppe. Viele Unterordner sind nach Bundle-Identifier benannt, zum Beispiel com.google.Chrome.
• /Library/Caches enthält systemweite Caches.
• /System ist durch System Integrity Protection geschützt und steht Ihnen nicht zur Verfügung. Versuchen Sie es nie.

Apple dokumentiert die Konvention der Bundle-Identifier, aber ein vertrauter Name ist kein Sicherheitszertifikat. Eine App kann eine Cache-Datenbank, Sitzungszustand und Downloads direkt nebeneinander ablegen. Apps in der Sandbox legen zugehöriges Material außerdem in Containers ab statt im obersten Caches-Ordner des Nutzers.

Apples Dateisystemübersicht reserviert /System/Library für Apple. Löschen Sie keinen Caches-Stamm rekursiv und ergänzen Sie bei Berechtigungsfehlern kein sudo.

Vor der Entscheidung den Inhalt einordnen

Alles, was eine App außerhalb ihres Bundles speichert, fällt in einen von drei Bereichen, und nur der erste ist als ersetzbar gedacht:

• Cache ist neu berechenbar: gerenderte Vorschaubilder, kompilierte Ausgaben oder heruntergeladene Dateien, die der Geschwindigkeit dienen. Das Löschen kann langsamere Starts, Netzwerknutzung und den Verlust der Offline-Verfügbarkeit bedeuten.
• Zustand ist Ihre Sitzung: offene Fenster, Scrollpositionen, Entwürfe. Der Verlust kann ungespeicherte Arbeit unwiederbringlich löschen.
• Daten sind unersetzlich: Ihre Nachrichten, Ihre Fotobibliothek, Ihre gespeicherten Anmeldungen. Das Löschen ist ein echter Verlust.

Die Ordner oben können diese vermischen, weshalb Tools zum „gesamten Cache leeren“ riskant sind. Ein Pfad unter ~/Library/Caches ist ein nützlicher Hinweis, aber kein vollständiger Sicherheitsbeweis.

Cache-Bereinigung ist gerechtfertigt, wenn ein gemessener Cache benötigten Speicher belegt, die dokumentierten Fehlerbehebungsschritte einer App sie vorsehen oder ein Index nachweislich veraltet oder beschädigt ist. Als Ritual ist sie nicht sinnvoll. macOS und viele Apps verdrängen Cache bereits unter Druck, und alles neu aufzubauen kann Leistung, Akkuverbrauch und Netzwerkverkehr kurzzeitig verschlechtern.

Application Support, Containers, Group Containers, Einstellungen, Schlüsselbund und versteckte Tool-Verzeichnisse gelten als Zustand oder Benutzerdaten, bis der Besitzer den Wiederaufbau eines bestimmten Unterordners dokumentiert.

Zuerst die größten Besitzer messen

Finden Sie Ihre größten Caches, bevor Sie etwas leeren:

du -sh ~/Library/Caches/* 2>/dev/null | sort -h
du -sh /Library/Caches/* 2>/dev/null | sort -h

Lesen Sie die größten Einträge am Ende und ordnen Sie sie einem Besitzer zu. Apples Mac-Speicherleitfaden beschreibt Systemdaten als Restkategorie, nicht als löschbaren Ordner.

Ist der Besitzer unklar, hören Sie dort auf. Ein 50-MB-Cache mit klarem Besitzer lässt sich besser beurteilen als ein undurchsichtiges 20-GB-Verzeichnis. Diese Zahlen sind Messwerte und kein Versprechen auf freien Speicher, denn Dateien können geöffnet bleiben, APFS teilt Blöcke über Klone und Snapshots, und Finder, du und die Systemeinstellungen gruppieren Speicher unterschiedlich.

Vor dem Löschen fünf Fragen beantworten

1. Welche App, welches Werkzeug oder welcher Dienst besitzt den Ordner?
2. Kann der Besitzer ihn neu aufbauen, und aus welcher Quelle?
3. Was kosten Zeit, Akku, Netzwerk und verlorene Offline-Verfügbarkeit?
4. Sind App, Downloader, Paketmanager und Modellserver beendet?
5. Gibt es Vorschau, Papierkorb oder einen klaren erneuten Download?

Bleibt eine Antwort offen, bleibt auch der Ordner.

Die Bereinigungsfunktion des Besitzers bevorzugen

Der Besitzer kennt Referenzen, geteilte Blobs, aktive Versionen und Dateien, die alt aussehen, aber weiterhin gebraucht werden. Seine Funktion kann weniger löschen und sicherer freigeben als ein rekursiver Befehl auf dem Dateisystem.

Browser

Chromes Anleitung zum Löschen von Browserdaten trennt Cache von Cookies, Verlauf, Passwörtern, Website-Einstellungen und Offline-Daten. Wählen Sie für Platzgewinn nur zwischengespeicherte Bilder und Dateien.

Andere Browser treffen ähnliche Unterscheidungen, auch wenn die Bezeichnungen abweichen. Nutzen Sie die Speicher- oder Datenschutzeinstellungen des Browsers und lesen Sie jede ausgewählte Kategorie. Löschen Sie nicht den Profilordner des Browsers, um einen Seitencache zu leeren.

Entwicklerwerkzeuge

Entwickler-Caches können groß werden, weil sie Speicherplatz gegen schnellere Builds und Installationen tauschen. Der Befehl muss zum Besitzer passen.

Homebrew beginnt mit brew cleanup --dry-run nach der offiziellen Dokumentation. npm beginnt mit npm cache verify; laut npm-Cache-Dokumentation ist ein erzwungenes Leeren im Normalfall unnötig. Xcode Derived Data ist neu erzeugbar, sofern Quellcode, Toolchain und Abhängigkeiten verfügbar sind. Das kann viel Build-Zeit und Energie kosten.

npm cache verify

Nutzen Sie nach Möglichkeit die Clean- oder Einstellungsfunktionen von Xcode für das gewählte Projekt. Vor dem manuellen Verschieben von DerivedData beenden Sie laufende Builds und Xcode. Paket-Repositories, Signaturmaterial, Simulatordaten und Quellcode-Checkouts sind keine Derived Data, nur weil sie zu einem Entwicklerwerkzeug gehören.

KI-Werkzeuge und heruntergeladene Modelle

hf cache ls
hf cache rm model/example --dry-run
hf cache prune --dry-run

ollama ls
ollama rm <model>

Hugging Face bietet hf cache ls, hf cache rm ... --dry-run und hf cache prune --dry-run in den Cache-Befehlen. Ollama listet Modelle mit ollama ls und entfernt nur das gewählte Modell mit ollama rm <model>, wie die CLI-Referenz beschreibt. Modelle, Chats, Zugangsdaten, Sitzungen und aktive Datenbanken sind kein allgemeiner Cache.

Beenden Sie die besitzende App immer zuerst. Cache-Dateien sind oft geöffnet oder memory-mapped, solange die App läuft, und sie mitten im Schreiben zu löschen kann die Cache-Datenbank beschädigen, auf die die App angewiesen ist, und aus einer Speicherbereinigung eine defekte App machen.

Browser-Cache verdient eine weitere Unterscheidung: Cookies, Website-Daten, Verlauf, gespeicherte Passwörter und zwischengespeicherte Seitenressourcen sind getrennte Steuerungen. Wählen Sie nur zwischengespeicherte Inhalte, wenn das Ziel Speicherfreigabe ist. Das Löschen aller Browserdaten kann Sie abmelden oder Offline-Website-Zustand entfernen, ohne spürbar mehr Cache freizugeben.

Das von Hand zu erledigen funktioniert, aber Bundle-Identifier und Ordnernamen sind nicht immer lesbar. Ein Cleaner sollte Eigentümer, Pfad, Größe und Kategorie zeigen, bevor er etwas anfasst, und Profile, Dokumente, Modellspeicher und Gesprächsverläufe von Design her ausschließen. Die Clean-Ansicht von Mole folgt diesem prüfungsorientierten Modell. Die breitere Lektion: Eine Skip-Liste und Pfadvalidierung zählen mehr als eine beeindruckende Anzahl gefundener Einträge.

Wenn manuelles Entfernen weiterhin nötig ist

Wenn der Besitzer keine passende Funktion anbietet, beenden Sie ihn, verschieben Sie genau einen identifizierten Cache-Unterordner in den Papierkorb und testen Sie danach Dokumente, Anmeldung, Offline-Daten, Einstellungen, Builds und Modelle. Apples Mac-Speicherleitfaden weist darauf hin, dass Platz erst nach dem Leeren des Papierkorbs frei wird. Nutzen Sie die Wartezeit als Wiederherstellungsfenster.

Die Details sind der Punkt. Eine sichere Implementierung nutzt nach Möglichkeit die eigene Bereinigungsschnittstelle des Paketmanagers, rührt Build-Cache nicht an, solange sein Daemon aktiv ist, validiert jeden aufgelösten Pfad, bricht langsame Größenmessungen ab und erhält explizit geschützte Ordner. Fehlt das besitzende Tool oder ist die Kategorie unklar, ist Prüfung sicherer als Raten. Eine rekursive Löschung eines gesamten Caches-Ordners umgeht jede dieser Prüfungen.

• Chatverläufe und Transkripte von KI-Assistenten. Sie liegen nahe an Caches, sind aber unersetzliche Daten. Löschen Sie sie nicht als vermeintlichen Cache, nur um Platz zu schaffen.
• Einstellungen und gespeicherte Anmeldungen, im Gegensatz zu entsorgbarem Cache.
• Alles unter /System.
• Jeden Ordner, dessen Zweck Sie nicht erkennen können.

Die Regel, die jede Mac-Bereinigung sicher hält: Wenn Sie nicht wissen, wofür eine Datei da ist, löschen Sie sie nicht.

Warum Cache und Systemdaten wieder wachsen

Messen Sie zuerst, beenden Sie den Eigentümer, nutzen Sie dessen integrierte Speicher- oder Bereinigungsfunktion, entfernen Sie eine Kategorie nach der anderen und öffnen Sie die App wieder, bevor Sie den Papierkorb leeren. Behandeln Sie Einstellungen, Profile, Chats, Dokumente oder unbekannte Application-Support-Daten nie als Cache. Leeren Sie nur, wenn der Speicher- oder Fehlerbehebungsnutzen die Kosten für Neuaufbau und Download übersteigt. Diese Methode ist langsamer als „alles löschen“, bleibt aber sicher, wenn sich App-Interna ändern.

Dass Cache wieder wächst, ist normal: Apps laden Dateien neu, erzeugen Vorschaubilder, kompilieren Ausgaben und bauen Indizes auf. Auch die Anzeige der Systemdaten kann später reagieren. Prüfen Sie realen freien Speicher und die besitzende App, statt weitere Kategorien zu löschen, nur um eine verzögerte Anzeige zu verfolgen.