# Ache arquivos grandes no Mac sem apagar os errados
> Leve em conta instantâneos do APFS, clones e espaço purgável, e classifique os arquivos grandes pelo dono antes de mover ou apagar.
Published: 2026-06-07 | Updated: 2026-10-18
O jeito mais rápido de achar o que está usando um disco é medi-lo, não folhear o Finder
pasta por pasta. A medição ainda precisa de interpretação: uma fototeca de 40 GB não
equivale a um instalador de 40 GB, e instantâneos do APFS, clones e capacidade purgável
podem fazer duas ferramentas corretas mostrarem totais com cara diferente.
Aqui está como o espaço em disco é contabilizado, como medi-lo e como achar os
itens grandes com segurança.
## Por que o disco está cheio mas os arquivos não fecham a conta
Macs modernos usam o sistema de arquivos APFS, e o APFS informa o espaço de um jeito diferente
do que o Finder mostra. Duas categorias escondem gigabytes:
- **Instantâneos locais.** O Time Machine guarda instantâneos de um ponto no tempo do seu disco no
disco interno entre backups. Eles seguram o espaço de arquivos que você já
apagou, porque o instantâneo ainda os referencia, até o macOS afiná-los.
A Apple diz que instantâneos de hora em hora em geral ficam por cerca de 24 horas e são
[removidos automaticamente](https://support.apple.com/102154) conforme envelhecem ou conforme o espaço
é necessário. Liste-os com:
```
tmutil listlocalsnapshots /
```
- **Espaço purgável.** O APFS marca caches, instantâneos locais e conteúdo que dá para baixar
de novo como purgável: espaço que o macOS recupera sozinho quando algo precisa dele.
O macOS pode contar isso como disponível, e o Finder pode incluí-lo no total
disponível. Você não consegue limpá-lo à mão de forma confiável.
Confira os números com:
```
df -h /
diskutil apfs list
diskutil apfs listSnapshots /
```
`df` informa o que o sistema de arquivos montado considera usado e disponível;
`diskutil apfs list` mostra o contêiner compartilhado, os volumes e a capacidade
restante; `diskutil apfs listSnapshots /` lista os instantâneos ligados ao volume de
inicialização. Quando o Finder diz que o disco está mais cheio do que os seus arquivos explicam, essas visões
ajudam a separar o uso comum de arquivos dos instantâneos e da capacidade compartilhada do APFS.
## Meça o uso real pela linha de comando
Para achar as pastas pesadas, `du` (uso de disco) é a ferramenta central. A partir da sua pasta
pessoal:
```
du -sh ~/* ~/Library 2>/dev/null | sort -h
```
`-s` dá um resumo por item, `-h` imprime tamanhos legíveis e o pipe para
`sort -h` põe o maior por último. Desça um resultado grande de cada vez. O Terminal pode
precisar de Acesso Total ao Disco para dados protegidos de apps, e uma varredura da pasta pessoal pode demorar
muito quando atravessa pastas de nuvem ou árvores de desenvolvimento.
O número nem sempre é alocação física. Hard links dão vários nomes ao
mesmo arquivo por baixo, e clones do APFS compartilham blocos até uma cópia mudar. Totais de
pasta e espaço livre do contêiner podem, portanto, responder perguntas diferentes. Use `du` para
localizar candidatos e então use Obter Informações do Finder e a visão de capacidade do APFS antes de fazer
uma exclusão de alto impacto.
Para achar arquivos grandes individuais em vez de pastas, `find` filtra por tamanho:
```
find ~/Downloads ~/Movies ~/Desktop -type f -size +500M -print 2>/dev/null
```
Comece por pastas sob o seu controle em vez de varrer o diretório pessoal inteiro. O
comando pode achar exportações de vídeo esquecidas, imagens de disco e arquivos compactados, mas essas pastas
ainda podem conter bancos ou arquivos sincronizados com a nuvem. Amplie as raízes só quando for necessário.
Para um mapa interativo no terminal, `ncdu` pode folhear uma pasta escolhida por tamanho. Trate-o
como uma ferramenta de descoberta só de leitura primeiro; mostre um candidato no Finder e mova-o para o Lixo
depois de identificá-lo, em vez de apagar de uma árvore desconhecida dentro do `ncdu`.
## Recupere o espaço escondido
Se o problema são instantâneos ou espaço purgável, e não um arquivo só,
liberar espaço real sob o seu controle dá folga ao macOS enquanto ele envelhece ou afina instantâneos
locais e caches purgáveis automaticamente. Reconectar um disco do Time Machine torna
mais histórico de backup disponível, mas não é um comando manual de purga de instantâneos. Você
raramente precisa forçar qualquer uma das duas categorias à mão.
## Um mapa visual, quando uma lista não basta
Um mapa de árvore da pasta pessoal: as pastas maiores são os blocos maiores, e um clique desce em qualquer uma delas. Esta é a visualização Analisar do Mole.
Tamanhos num terminal são úteis, mas difíceis de segurar na cabeça ao longo de um disco inteiro.
Um mapa de árvore resolve isso desenhando cada pasta como um retângulo na escala do tamanho,
então as coisas maiores são os blocos maiores e um olhar mostra onde o peso
está. A visualização Analisar do [Mole](https://mole.fit/) é a contraparte gráfica da caminhada por caminho
acima: ela mapeia o disco inteiro a partir da raiz, desce com um clique e deixa você
mostrar um item no Finder ou enviá-lo ao Lixo (pelo menu de clique com o botão direito, com uma
confirmação de tamanho, e recuperável até o Lixo ser esvaziado). Raízes de navegação
como a sua pasta pessoal não têm opção de apagar, então um clique errado não remove algo
estrutural. Use o que preferir; o mapa de árvore e os comandos respondem à mesma
pergunta.
## Por dentro: como um analisador de disco continua rápido
Você não precisa desta parte para liberar espaço, mas se já se perguntou por que um
bom mapa de disco volta em segundos onde um script ingênuo rasteja, aqui está a forma
dele. O exemplo é a [ferramenta de linha de comando de código aberto do Mole](https://github.com/tw93/Mole),
especificamente o analisador em Go em `cmd/analyze`. O app nativo tem um scanner Swift
separado, mas os dois mantêm a concorrência limitada e deduplicam hard links.
No analisador da CLI, a fila limita o trabalho pendente, orçamentos separados limitam os caminhantes de diretório e os processos du, a deduplicação de hard link conta cada byte uma vez, e heaps Top-N evitam ordenar a árvore inteira.
O jeito lento é o óbvio: caminhar cada pasta, dar `stat` em cada arquivo, somar tudo
e então ordenar. Num diretório pessoal com milhões de arquivos pequenos isso é ao mesmo tempo lento
e guloso de memória. O scanner evita as duas armadilhas com três ideias.
**Limitado, mas não com um limite só.** Paralelismo ingênuo cria uma goroutine por
pasta e derrete o disco. O scanner mantém orçamentos separados para recursos
separados: um pool de trabalhadores de diretório (2 a 12, na escala dos seus núcleos), um
pool bem menor de no máximo quatro subprocessos `du` concorrentes (porque caminhadas de
diretório demais competindo podem saturar a E/S de disco) e um
limite de fila para o trabalho pendente nunca inflar para milhares de goroutines empilhadas.
Colapsar isso num limite só é como as ferramentas de disco acabam lentas ou
gulosas de memória.
**Guarde só os vencedores.** Você quer as pastas maiores, não todas, então o
scanner nunca ordena o disco inteiro. Ele passa cada item medido por dois
heaps mínimos, um com as 30 maiores pastas e outro com os 20 maiores arquivos. Quando um heap está
cheio, um item novo é comparado com o menor sobrevivente e descartado se não
o superar. Isso é mais ou menos linear no número de arquivos e segura só algumas
dezenas de entradas na memória, em vez de ordenar milhões.
**Conte cada byte uma vez.** Um arquivo com vários hard links seria somado
uma vez por link. O scanner registra o par `(device, inode)` de cada arquivo na primeira
vez que o vê e pula as repetições, e é assim que os totais batem com `du`. Ele até
se recusa a guardar em cache um total de pasta que dependeu dessa deduplicação, porque esse número
depende da ordem da varredura e envenenaria uma nova varredura isolada depois.
Nada disso é exótico. É a diferença entre uma ferramenta que responde "o que está
enchendo o meu disco" com eficiência e uma que gasta recursos gerenciando a própria varredura.
Esses detalhes descrevem a CLI; o mapa de árvore nativo acima usa o próprio scanner Swift.
## Classifique antes de remover qualquer coisa
Achar um item grande não é permissão para apagá-lo. Ponha cada candidato num de
três baldes:
- **Substituível:** instaladores verificados, saída de build reproduzível e caches
documentados. Confira o custo de baixar ou reconstruir antes de remover.
- **Pessoal ou operacional:** fotos, mensagens, arquivos de projeto, discos de máquina
virtual, pesos de modelo e backups de aparelho. Exporte, faça backup ou aposente pelo
app dono.
- **Gerenciado pelo app ou pelo sistema:** bancos de pacotes, contêineres, bibliotecas do Fotos ou do Mail,
instantâneos e qualquer coisa em `/System`. Use os controles do app ou deixe
em paz.
Se uma pasta grande pertence a um app que você não usa mais, siga o desinstalador
documentado e então [revise os restos](https://mole.fit/pt-br/blog/how-to-completely-uninstall-apps-on-mac).
Mova arquivos comuns para o Lixo primeiro e deixe-os lá até o app e o
projeto afetados ainda funcionarem. Esvaziar o Lixo é o passo irreversível.
Para a limpeza mais ampla, além de arquivos grandes isolados, veja
[como liberar espaço sem perder arquivos](https://mole.fit/pt-br/blog/how-to-free-up-space-on-mac).
## Um método que dá para repetir
Primeiro compare `df`, a capacidade do APFS e os ajustes de Armazenamento para saber se o problema
é pressão física real ou classificação. Depois meça raízes escolhidas, desça no
ramo maior e classifique o candidato por dono e por possibilidade de recuperação. Remova
dados substituíveis primeiro, trate dados pessoais por backups e apps donos, e mantenha
exclusões comuns recuperáveis no Lixo até você ter conferido o resultado.
---
Canonical HTML page: https://mole.fit/pt-br/blog/how-to-find-large-files-on-mac
Blog index for agents: https://mole.fit/pt-br/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
