# Mac-Caches leeren, ohne Daten zu verlieren
> Cache von Zustand und Nutzerdaten trennen, den Eigentümer messen, seine Bereinigungsfunktion nutzen und die App prüfen, bevor der Papierkorb geleert wird.
Published: 2026-06-17 | Updated: 2026-08-08
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, was jede Art ist, wo sie liegt und wie Sie sie ohne
Begleitschäden leeren.
## Cache, Zustand und Daten sind drei verschiedene Dinge
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 ist ärgerlich, aber nicht katastrophal.
- **Daten** sind unersetzlich: Ihre Nachrichten, Ihre Fotobibliothek, Ihre
gespeicherten Anmeldungen. Das Löschen ist ein echter Verlust.
Ein Cache-Hit liefert sofort. Ein Miss holt die Quelldaten, baut die entsorgbare Kopie neu auf und speichert sie für die nächste Anfrage.
Die Ordner unten 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.
## Einen Cache mit gutem Grund leeren
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.
## Wo Cache auf einem Mac liegt
- `~/Library/Caches/` enthält nutzerbezogene App-Caches, die größte alltägliche
Gruppe. Jeder Unterordner ist 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.
Einstellungen verdienen eine besondere Warnung. Dateien in
`~/Library/Preferences` sind Ihre Einstellungen, kein Cache, und macOS hält sie
über einen Daemon namens `cfprefsd` im Speicher. Eine `.plist` von Hand zu
löschen, während die App läuft, kann Einstellungen verlieren, durch den aktiven
Einstellungszustand überschrieben werden oder App und zwischengespeicherten
Zustand auseinanderlaufen lassen. Ändern Sie Einstellungen zuerst in der App.
Nutzen Sie `defaults` nur für eine dokumentierte Preference-Domain und einen
dokumentierten Schlüssel, nicht als generischen Bereinigungsbefehl.
## Die Caches, die sich lohnen, und die großen
Finden Sie Ihre größten Caches, bevor Sie etwas leeren:
```
du -sh ~/Library/Caches/* 2>/dev/null | sort -h
```
Die schwersten Zeilen sind in der Regel:
- **Browser.** Safari, Chrome und andere halten Gigabyte an zwischengespeicherten
Seiten und Medien. Leeren Sie diese in den eigenen Einstellungen des Browsers;
das ist sicherer als den Ordner zu löschen, weil Cache von Verlauf und
Anmeldungen getrennt bleibt.
- **Entwicklertools**, die auf einem Coding-Mac alles andere in den Schatten
stellen. Xcodes `~/Library/Developer/Xcode/DerivedData` kann Dutzende
Gigabyte erreichen, und Paketmanager führen eigene Speicher:
`brew cleanup` entfernt alte Homebrew-Downloads, `npm cache clean --force`
leert den npm-Cache, und `~/Library/Caches/` hält Caches für Swift Package
Manager, pip und andere. Der npm-Cache heilt sich selbst, beginnen Sie daher
mit `npm cache verify`; `npm cache clean --force` behalten Sie für eine
bewusste Speicher- oder Fehlerbehebung vor.
- **QuickLook-Vorschaubilder**, bei Bedarf neu aufgebaut: `qlmanage -r 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.
## Der sicherere Weg, nach Kategorie mit Prüfung
Nach einer geprüften Bereinigung zeigt der Abschlussbildschirm den tatsächlich freigegebenen Speicher, nicht eine Schätzung. Das ist die Clean-Ansicht von Mole.
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](https://mole.fit/)
folgt diesem prüfungsorientierten Modell. Die breitere Lektion: Eine Skip-Liste
und Pfadvalidierung zählen mehr als eine beeindruckende Anzahl gefundener
Einträge.
## Unter der Haube: was „sicher zu leeren“ tatsächlich prüft
Sie können diesen Abschnitt überspringen, aber er zeigt, warum „nach Kategorie mit
Prüfung leeren“ mehr als ein Slogan ist. So sehen die Checks in der Praxis aus,
aus der Cache-Logik im [Open-Source-Kommandozeilentool von Mole](https://github.com/tw93/Mole)
(`lib/clean`). Die native App spiegelt viele dieser Regeln in Swift, statt die
CLI aufzurufen.
Ein Kandidat erreicht den Papierkorb nur über Prüfung und Bestätigung. Tool-Zustand, explizite Guard-Dateien und geschützte Domains entscheiden, ob er in die Prüfung kommt oder unberührt bleibt.
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.
## Was Sie nicht leeren sollten, auch nicht im Namen von Cache
- **Chatverläufe und Transkripte von KI-Assistenten.** Sie liegen nahe an
Caches, sind aber unersetzliche Daten. Löschen Sie sie nie freier Speicher
wegen.
- **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.
## Eine sichere Cache-Bereinigungssequenz
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.
---
Canonical HTML page: https://mole.fit/de/blog/how-to-clear-cache-on-mac
Blog index for agents: https://mole.fit/de/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
