# Trovare e rimuovere file grandi sul Mac in sicurezza
> Interpreta snapshot APFS, clone e capacità liberabile, poi classifica i file grandi per proprietà e recuperabilità prima di eliminarli.
Published: 2026-06-07 | Updated: 2026-08-08
Il modo più veloce per capire cosa sta usando il disco è misurarlo, non scorrere Finder
cartella per cartella. La misurazione va comunque interpretata: una libreria Photos da
40 GB non equivale a un installer da 40 GB, e snapshot APFS, cloni e capacità
purgeable possono far sembrare diversi i totali di due strumenti entrambi corretti.
Ecco come viene contabilizzato lo spazio su disco, come misurarlo e come trovare in
sicurezza gli elementi grandi.
## Perché il disco è pieno ma i file non tornano
I Mac moderni usano il file system APFS, e APFS riporta lo spazio in modo diverso da
quello che mostra Finder. Due categorie nascondono gigabyte:
- **Snapshot locali.** Time Machine conserva snapshot point-in-time del disco sulla
unità interna tra un backup e l'altro. Bloccano lo spazio dei file che hai già
eliminato, perché lo snapshot li referenzia ancora, finché macOS non li riduce.
Apple indica che gli snapshot orari restano di norma per circa 24 ore e vengono
[rimossi automaticamente](https://support.apple.com/102154) con l'età o quando serve
spazio. Elencali con:
```
tmutil listlocalsnapshots /
```
- **Spazio purgeable.** APFS segna cache, snapshot locali e contenuti ridscaricabili
come purgeable: spazio che macOS recupera da solo quando qualcosa ne ha bisogno.
macOS può contarlo come disponibile, e Finder può includerlo nel totale
disponibile. Non si può liberarlo in modo affidabile a mano.
Controlla i numeri con:
```
df -h /
diskutil apfs list
diskutil apfs listSnapshots /
```
`df` riporta ciò che il file system montato considera usato e disponibile.
`diskutil apfs list` mostra il container condiviso, i suoi volumi e la capacità
rimanente. `diskutil apfs listSnapshots /` elenca gli snapshot legati al volume di
avvio. Quando Finder dice che il disco è più pieno di quanto i file spieghino, queste
viste aiutano a separare l'uso ordinario dei file da snapshot e capacità APFS condivisa.
## Misurare l'uso reale dalla riga di comando
Per trovare le cartelle pesanti, `du` (disk usage) è lo strumento centrale. Dalla
cartella home:
```
du -sh ~/* ~/Library 2>/dev/null | sort -h
```
`-s` dà un riepilogo per elemento, `-h` stampa dimensioni leggibili e l'inoltro a
`sort -h` mette le più grandi in fondo. Scendi in un risultato grande alla volta. Terminal
può richiedere Full Disk Access per i dati protetti delle app, e una scansione della home
può richiedere molto tempo se attraversa cartelle cloud o alberi di sviluppo.
Il numero non è sempre l'allocazione fisica. Hard link danno più nomi allo stesso
file sottostante, e i cloni APFS condividono i blocchi finché una copia non cambia. I
totali delle cartelle e lo spazio libero del container possono quindi rispondere a
domande diverse. Usa `du` per individuare i candidati, poi Get Info di Finder e la
vista capacità APFS prima di una cancellazione ad alto impatto.
Per trovare singoli file grandi invece delle cartelle, `find` filtra per dimensione:
```
find ~/Downloads ~/Movies ~/Desktop -type f -size +500M -print 2>/dev/null
```
Parti dalle cartelle controllate dall'utente invece di scansionare l'intera home. Il
comando intercetta export video dimenticati, immagini disco e archivi senza
attraversare ogni database delle applicazioni. Amplia l'elenco delle radici solo se
serve. Per una mappa interattiva nel terminale, `ncdu` può navigare una cartella
selezionata per dimensione. Trattalo prima come strumento di scoperta in sola lettura;
rivela un candidato in Finder e spostalo nel Cestino dopo averlo identificato, invece di
eliminare da un albero sconosciuto dentro `ncdu`.
## Recuperare lo spazio nascosto
Se il problema sono snapshot o spazio purgeable piuttosto che un singolo file,
liberare spazio reale controllato dall'utente dà a macOS margine mentre invecchia o
riduce automaticamente snapshot locali e cache purgeable. Ricollegare un disco Time
Machine rende disponibile più cronologia di backup, ma non è un comando di purge
manuale degli snapshot. Raramente serve forzare a mano nessuna delle due categorie.
## Una mappa visiva, quando un elenco non basta
Una treemap dell'intero disco: le cartelle più grandi sono i blocchi più grandi, e un clic scende in una di esse. Questa è la vista Analyze di Mole.
Le dimensioni nel terminale sono utili ma difficili da tenere a mente su un intero
disco. Una treemap lo risolve disegnando ogni cartella come un rettangolo proporzionale
alla sua dimensione, così le cose più grandi sono i blocchi più grandi e a colpo
d'occhio si vede dove sta il peso. La vista Analyze di [Mole](https://mole.fit/) è la controparte
grafica del percorso a livello di path sopra: mappa l'intero disco dalla radice,
scende con un clic e permette di rivelare un elemento in Finder o di inviarlo al
Cestino (dal menu del clic destro, con conferma della dimensione, e recuperabile finché
il Cestino non viene svuotato). Le radici di navigazione come la cartella home non
hanno opzione di eliminazione, così un clic sbagliato non può rimuovere qualcosa di
strutturale. Usa ciò che preferisci; la treemap e i comandi rispondono alla stessa
domanda.
## Dietro le quinte: come un disk analyzer resta veloce
Non ti serve questa parte per liberare spazio, ma se ti sei mai chiesto perché una
buona mappa del disco torna in pochi secondi dove uno script ingenioso striscia, ecco
la forma del problema. L'esempio è [lo strumento da riga di comando open-source di
Mole](https://github.com/tw93/Mole), in particolare il suo analyzer Go in
`cmd/analyze`. L'app nativa ha uno scanner Swift separato, ma entrambi tengono la
concorrenza limitata e deduplicano gli hard link.
Nell'analyzer CLI, la coda limita il lavoro in sospeso, budget separati limitano i walker di directory e i processi du, la dedup degli hard link conta ogni byte una sola volta, e gli heap Top-N evitano di ordinare l'intero albero.
Il modo lento è quello ovvio: scorrere ogni cartella, fare `stat` su ogni file,
sommare tutto, poi ordinare. Su una home con milioni di file piccoli è sia lento sia
affamato di memoria. Lo scanner evita entrambe le trappole con tre idee.
**Limitato, ma non con un unico limite.** Il parallelismo ingenuo genera una
goroutine per cartella e fonde il disco. Lo scanner tiene invece budget separati per
risorse separate: un pool di worker di directory (da 2 a 12, in scala con i core), un
pool molto più piccolo di al massimo quattro sottoprocesi `du` concorrenti (perché
`du` è già parallelo in I/O, e avviarne di più fa solo thrashare il disco), e un
limite di coda così che il lavoro in sospeso non si gonfi in migliaia di goroutine
impilate. Collassare tutto in un unico limite è come i tool del disco finiscono
lenti o affamati di memoria.
**Tieni solo i vincitori.** Vuoi le cartelle più grandi, non tutte, quindi lo scanner
non ordina mai l'intero disco. Inoltra ogni elemento misurato attraverso due
min-heap, uno con le Top 30 cartelle e uno con i Top 20 file. Quando un heap è
pieno, un nuovo elemento si confronta con il sopravvissuto più piccolo e viene
scartato se non lo batte. È pressoché lineare nel numero di file e tiene in memoria
solo poche decine di voci, invece di ordinare milioni di elementi.
**Conta ogni byte una sola volta.** Un file con più hard link altrimenti verrebbe
sommato una volta per link. Lo scanner registra la coppia `(device, inode)` di ogni
file la prima volta che la vede e salta le ripetizioni, ed è così che i totali
corrispondono a `du`. Rifiuta anche di mettere in cache un totale di cartella che
dipendeva da questa dedup, perché quel numero dipende dall'ordine di scansione e
avvelenerebbe una successiva ri-scansione isolata.
Niente di tutto questo è esotico. È la differenza tra uno strumento che risponde
"cosa sta riempiendo il disco" in pochi secondi e un loop shell che non lo fa, e la
treemap sopra è il front end di esattamente questo motore.
## Classifica prima di rimuovere qualsiasi cosa
Trovare un elemento grande non è un permesso a eliminarlo. Metti ogni candidato in
uno di tre secchi:
- **Sostituibile:** installer verificati, output di build riproducibili e cache
documentate. Valuta il costo di riscaricarli o ricostruirli prima della rimozione.
- **Personale o operativo:** foto, messaggi, archivi di progetto, dischi di macchine
virtuali, pesi di modelli e backup di dispositivi. Esporta, fai backup o ritira
questi elementi attraverso l'app proprietaria.
- **Gestito dall'app o dal sistema:** database di pacchetti, container, librerie
Photos o Mail, snapshot e qualsiasi cosa sotto `/System`. Usa i controlli dell'app
o lascialo stare.
Se una cartella grande appartiene a un'app che non usi più, segui il suo
disinstallatore documentato e poi [controlla i residui](https://mole.fit/it/blog/how-to-completely-uninstall-apps-on-mac).
Sposta prima i file ordinari nel Cestino e tienili lì finché l'app e il progetto
interessati funzionano ancora. Svuotare il Cestino è il passo irreversibile.
Per la pulizia più ampia oltre i singoli file grandi, vedi
[come liberare spazio senza perdere file](https://mole.fit/it/blog/how-to-free-up-space-on-mac).
## Un metodo ripetibile
Prima confronta `df`, capacità APFS e impostazioni di Archiviazione così sai se il
problema è pressione fisica reale o classificazione. Poi misura radici selezionate,
scendi nel ramo più grande e classifica il candidato per proprietà e recuperabilità.
Rimuovi prima i dati sostituibili, gestisci i dati personali tramite backup e app
proprietarie, e tieni le eliminazioni ordinarie recuperabili nel Cestino finché non
hai verificato il risultato.
---
Canonical HTML page: https://mole.fit/it/blog/how-to-find-large-files-on-mac
Blog index for agents: https://mole.fit/it/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
