~/Library/Caches: A Única Pasta Por Trás de Metade Deste Blog

Se você já leu mais de um artigo neste blog, deve ter notado um padrão: DerivedData, caches de navegador, caches de apps Electron, CocoaPods, índices do JetBrains — uma fatia enorme deles mora em algum lugar dentro de um único diretório. Vale a pena olhar para esse diretório diretamente, uma vez, em vez de app por app.

open ~/Library/Caches

O Finder esconde ~/Library por padrão — segure Option enquanto clica no menu Ir do Finder para revelá-lo, ou use o comando open acima, que ignora completamente o ajuste de pasta oculta.

Por que essa pasta existe e por que é segura por construção

~/Library/Caches é o próprio local designado pela Apple exatamente para esse propósito — dados que qualquer app pode regenerar ou baixar de novo, que o sistema operacional tem permissão explícita para apagar sob pressão de disco. Não é uma convenção que desenvolvedores inventaram; é uma parte documentada da estrutura de arquivos da Apple, e todo app bem-comportado do Mac deveria usá-la para qualquer coisa não essencial.

Esse único fato é o que torna essa pasta incomumente segura para limpar de forma ampla, comparado a quase qualquer outro lugar do seu disco: pelo próprio design da Apple, nada aqui deveria ser a única cópia de algo que importa. As exceções práticas — um punhado de apps que usam mal a pasta Caches para dados que não são realmente descartáveis — são raras o suficiente para valer a pena nomear especificamente, o que este artigo faz abaixo.

Lendo diretamente, ordenado por tamanho

du -sh ~/Library/Caches/* 2>/dev/null | sort -hr | head -30

Em praticamente qualquer Mac usado há mais de um ano, esse único comando traz à tona exatamente os mesmos nomes cobertos nos outros guias deste blog: com.apple.Safari, Google/Chrome, org.swift.swiftpm, Homebrew, CocoaPods, pip, JetBrains, além de dezenas de entradas menores de apps que você nunca pensaria em checar individualmente.

Os nomes das pastas são quase sempre identificadores de pacote em DNS reverso (com.company.AppName) ou nomes de pacote simples (pip, Homebrew) — se você ver um que não reconhece, mdfind "kMDItemCFBundleIdentifier == '<the-name>'" geralmente vai te dizer a qual app instalado ele pertence.

A abordagem seguro-por-completo

Para a maioria das pessoas, na maior parte do tempo, isso é genuinamente tranquilo:

rm -rf ~/Library/Caches/*

Todo app bem-comportado reconstrói o que precisa dessa pasta na próxima vez que roda — esse é todo o propósito de o diretório existir. O custo visível é a soma de cada custo individual coberto em outros lugares deste blog: navegadores buscam recursos de novo, gerenciadores de pacotes baixam de novo na próxima instalação, o índice do Xcode se reconstrói, e assim por diante — nada quebra, várias coisas ficam brevemente mais lentas.

As exceções que vale a pena conhecer pelo nome

Um pequeno número de apps usa a subpasta Caches deles para dados mais caros de perder do que a palavra “cache” sugere, cobertos em mais detalhe em seus próprios artigos:

• O IndexedDB do Slack pode guardar rascunhos de mensagens não enviadas — veja o guia sobre Slack e Discord.
• O IndexedDB de qualquer app usado como armazenamento local-first (alguns PWAs, alguns apps de anotações) — veja o guia de cache de navegador.
• O cache do Docker tecnicamente mora fora dessa pasta por completo — está dentro de uma imagem de disco de VM em ~/Library/Containers, não em ~/Library/Caches, o que vale a pena saber para que uma limpeza geral do Caches não crie a falsa sensação de ter resolvido o Docker também. Veja o guia de espaço em disco do Docker.

Tudo o mais coberto neste blog — a DerivedData tecnicamente mora dentro de ~/Library/Developer, não ~/Library/Caches, outra pasta que vale a pena conhecer e que fica bem fora do raio de ação desta — ou está diretamente dentro de ~/Library/Caches ou é regido pelo mesmo princípio de “seguro para regenerar”, mesmo quando a Apple arquivou num diretório de nível superior ligeiramente diferente.

Por que uma varredura vence uma exclusão em massa de qualquer forma

rm -rf ~/Library/Caches/* é seguro, mas também é cego — não consegue te dizer quais três apps são responsáveis por 40 dos 45 GB ali dentro, e não consegue te avisar sobre a exceção do IndexedDB do Slack acima antes que ela aconteça. Uma análise byte a byte, ordenada e nomeada, transforma “limpe a pasta de cache e torça” em “aqui estão as quatro coisas que realmente valem a pena conhecer, em ordem”.

O DevCruft está sendo projetado para ler exatamente essa pasta — além da DerivedData, do armazenamento de containers do Docker, e de tudo mais que mora logo fora dela — e mostrar a mesma análise ordenada que o comando du acima produz, só que com cada item rotulado pelo que ele realmente é e se é seguro, em vez de um identificador de pacote que você precisa procurar manualmente. É um app gratuito para Mac ainda em desenvolvimento; entre na lista de espera para saber quando ele for lançado.

Este é o último de dez guias adicionados nesta rodada. Para o tour original e mais amplo de tudo que enche o Mac de um desenvolvedor, comece com o guia completo de armazenamento para desenvolvedores.