# Mac 快取刪除：~/Library/Caches 怎麼判斷 > 區分快取與狀態／資料，確認所有者與容量後再刪，刪完驗證 App 是否正常。 Published: 2026-06-17 | Updated: 2026-09-12 真正的快取可以重新產生，但名稱裡有 Cache 的目錄不一定能刪。Apple 的 [Library 目錄說明](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html)把快取定義為可重新產生、App 不應依賴其持續存在的內容。動手前要知道檔案屬於誰、從哪裡重建，以及刪除後會失去什麼。
一次快取查詢會進入命中或未命中分支，未命中時重新取得來源資料並建立快取
快取未命中時，App 會重新取得來源資料並產生副本。
命中時 App 直接讀本機副本繼續跑，未命中就回到來源重新取一份，再決定要不要存下來。說不出這個來源在哪裡，就沒辦法判斷一次未命中還能不能恢復。 ## `~/Library/Caches` 和 `/Library/Caches` 的範圍不一樣 - `~/Library/Caches` 保存目前使用者的 App 快取，子目錄通常使用 Bundle ID，例如 `com.google.Chrome` - `/Library/Caches` 保存系統範圍的快取 - `/System` 受到系統完整性保護，不在手動清理範圍內 Apple 記錄了以 Bundle ID 命名子目錄的慣例，但眼熟的名稱不等於安全證明。同一個 App 可能把快取資料庫、工作階段狀態和下載內容並排放在一起，沙盒 App 還會把相關內容放進 Containers，而不是使用者 Caches 根目錄。 Apple 的[檔案系統說明](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html)明確把 `/System/Library` 留給系統。不要遞迴刪除任一 Caches 根目錄，也不要把權限錯誤當成在通用清理指令加入 `sudo` 的理由。 ## 決定之前先給內容分類 | 類型 | 常見內容 | 刪除後會發生什麼 | 預設處理 | | --- | --- | --- | --- | | 快取 | 縮圖、編譯輸出、可重新下載的副本 | 首次開啟變慢，增加耗電與流量 | 確認歸屬後，使用 App 自己的清理介面 | | 狀態或工作階段 | 視窗、分頁、Cookie、草稿、登入憑證 | 遺失工作現場、登入狀態或離線連續性 | 保留，除非 App 提供明確重設項目 | | 資料庫或索引 | `.db`、`.sqlite`、加密索引、內容定址目錄 | 可能遺失搜尋、離線紀錄或唯一的本機副本 | 只有所屬工具明確說明可重建時才處理 | | 使用者資料 | 文件、照片、郵件、聊天、模型與憑證 | 永久遺失，或需要大量重新下載 | 不當成快取處理 | 同一個目錄可能混合三類內容。`~/Library/Caches` 是判斷線索，不能單獨證明整個目錄都能刪除。 適合清理的情況有三種：快取確實占用了急需空間，App 的官方疑難排解文件要求清理，索引已經確認損毀或過期。macOS 和許多 App 會在空間緊張時自動淘汰快取。定期全部清空，反而會暫時拖慢啟動，並增加耗電和下載量。 Application Support、Containers、Group Containers、偏好設定、鑰匙圈和隱藏的工具目錄，預設都按狀態或使用者資料處理。只有所屬工具明確說明其中某個子目錄可以重建，才把它歸入快取。 ## 先量出最大的那幾個所屬工具 ```shell du -sh ~/Library/Caches/* 2>/dev/null | sort -h du -sh /Library/Caches/* 2>/dev/null | sort -h ``` 從下往上讀，最後幾行就是最大的那幾項，把每一項對上具體的 App、Bundle ID 或有文件說明的工具快取，認不出所屬工具就停在那裡。一個 50 MB、所屬工具明確的快取，比一個 20 GB 的不明目錄更值得評估。這些數字只是測量結果，不是可回收空間的承諾，檔案可能仍被開啟，APFS 會透過複製和快照共用資料區塊，Finder、`du` 和系統設定對儲存空間的歸類方式也不一樣。 遇到權限錯誤就停下來，不要為了列出完整結果加入 `sudo`。 `~/Library/Caches` 只影響目前使用者，`/Library/Caches` 範圍更大，可能服務多個帳號或系統元件。 系統設定裡的「系統資料」只是未歸入其他類別的彙總，不是一個目錄。Apple 的 [Mac 儲存空間說明](https://support.apple.com/102624)也採用這個分類，因此應以具體所屬目錄和實際可用空間判斷成果。 ## 刪除前先回答五個問題 1. 這個目錄屬於哪個 App、命令列工具或系統服務 2. 所屬工具能否重建，來源是原始檔還是遠端下載 3. 快取未命中會花多少編譯時間、電力、網路流量與離線能力 4. App、下載器、套件管理工具或模型服務是否仍在執行 5. 永久刪除前是否有預覽、垃圾桶或明確的重新下載路徑 其中任何一項答不出來，就先保留。 ## 優先使用所屬工具的清理介面 所屬工具知道哪些內容還被引用、哪些 blob 是共用的、哪個版本仍在使用，也知道哪些檔案看著舊卻仍然必需，所以它自己的清理介面往往刪得更少，回收得也更穩。 ### 瀏覽器 瀏覽器快取可能達到數 GB。Chrome 的[清除瀏覽資料說明](https://support.google.com/chrome/answer/2392709?hl=en-uk)把快取圖片與檔案和瀏覽紀錄、Cookie、密碼、網站設定及離線資料分開。只想釋放快取空間時，只選「快取圖片和檔案」，不要刪除整個瀏覽器描述檔目錄。 其他瀏覽器只是叫法不同，分類方式差不多，從瀏覽器自己的儲存空間或隱私設定進去，把勾選的每一項都讀一遍再確認。 ### 開發工具 開發工具的快取往往很大，因為它們拿磁碟空間換建置和安裝速度，所以清理指令要對上具體的所屬工具。 Xcode Derived Data 可以重建，但代價是編譯時間和電力。Homebrew 先依[官方清理說明](https://docs.brew.sh/Manpage.html#cleanup-options-formulacask-)執行 `brew cleanup --dry-run` 預覽，再決定是否執行 `brew cleanup`。npm 應先執行 `npm cache verify`；[npm 快取文件](https://docs.npmjs.com/cli/v11/commands/npm-cache/)說明，除非為了明確的空間回收或疑難排解，不需要把 `npm cache clean --force` 當作日常維護。 ```bash npm cache verify ``` 先確認原始碼、相依套件和工具鏈仍可用，再結束 Xcode 與相關建置、測試，只處理準備重建的專案，並盡量使用 Xcode 自己的清理或設定入口。套件庫、簽名素材、模擬器資料和原始碼，不會因為同屬開發工具就變成 Derived Data。 ### AI 工具和下載的模型 ```bash hf cache ls hf cache rm model/example --dry-run hf cache prune --dry-run ``` ```bash ollama ls ollama rm ``` AI 工具尤其要用自己的管理介面。Hugging Face 先用 `hf cache ls` 查看模型與版本，再用 `hf cache rm model/example --dry-run` 或 `hf cache prune --dry-run` 預覽，參數以 [Hugging Face 快取指令](https://huggingface.co/docs/huggingface_hub/main/en/guides/cli#hf-cache)為準；Ollama 先用 `ollama ls` 查看模型，再依 [Ollama CLI 說明](https://github.com/ollama/ollama/blob/main/docs/cli.mdx)用 `ollama rm ` 刪除明確選中的模型。模型是主動下載的內容，不是一般 快取，聊天紀錄、憑證、工作階段、設定與使用中的資料庫也不能順手清除。 清理前先結束對應 App。執行中的 App 可能正在寫入或以記憶體對應方式使用快取，直接刪除會損毀快取資料庫。 瀏覽器裡的 Cookie、網站資料、瀏覽紀錄、密碼和頁面快取是不同選項。只想釋放空間時，選擇快取內容即可。清除全部瀏覽資料可能讓網站登出，卻不一定多釋放多少空間。
清理完成頁面顯示實際釋放 86.4 GB，並說明快取已經清理
清理完成後顯示實際釋放的空間。這是 Mole 的「清理」檢視。
手動清理沒有問題，只是 Bundle ID 和目錄名稱不總是好認。清理工具應在操作前顯示歸屬、路徑、大小和類別，並預設排除設定檔、文件、模型目錄和聊天紀錄。[Mole](https://mole.fit/tw/) 的「清理」檢視採用清理前確認的方式。明確哪些內容會略過，並對每條路徑重新驗證，比掃描出多少檔案更重要。 ## 仍需手動處理時 手動處理應放在最後：結束所屬 App 和相關背景程序，只把一個已確認的快取子目錄移到垃圾桶，重新開啟 App 並重做原本的工作，再檢查文件、登入、離線資料、偏好、建置產物與模型是否正常。Apple 的 [Mac 儲存空間說明](https://support.apple.com/102624)提醒，檔案移到垃圾桶後，必須清空垃圾桶才會真正釋放空間。這個延遲正好提供恢復窗口。 Mole 的開源命令列工具在 `lib/clean` 中展示了同類檢查，原生 App 用 Swift 實作同類規則。
快取候選項目先經過有逾時的容量檢查與安全規則，再進入確認，執行中的工具、保護檔案與受保護目錄會讓它被略過
工具狀態、保護檔案和受保護目錄會決定候選項目進入確認，還是留在原位。
較穩妥的實作會優先呼叫套件管理工具自己的清理介面，避開仍被背景服務使用的建置快取，對解析後的路徑再次驗證，並為緩慢的容量探測設定逾時。所屬工具不存在、路徑含義不清或目錄被明確保護時，保留比猜測更合適，遞迴刪除整個 Caches 目錄會繞過這些判斷。 - AI 助理的聊天歷程和對話紀錄 - 偏好設定和已儲存的登入資訊 - `/System` 下的內容 - 無法確認用途的目錄 ## 為什麼快取和系統資料還會長回來 一個相對容易複核的順序是：測量大小和歸屬，結束 App，使用 App 自己的儲存空間設定或清理指令，並一次處理一個類別。重新開啟 App，確認登入、離線內容和專案仍正常後，再清空垃圾桶。偏好設定、描述檔、聊天、文件和含義不明的 Application Support 資料，本來就不算快取。 快取再次長大通常是正常現象，App 會重新下載檔案、產生縮圖、編譯輸出並建立索引。系統設定裡的「系統資料」是未歸入其他類別的總和，不是一個可直接刪除的目錄，統計也可能晚於實際檔案變化。清理後看實際可用空間與 App 是否正常，不要為了追逐延遲更新的分類而擴大刪除範圍。 --- Canonical HTML page: https://mole.fit/tw/blog/how-to-clear-cache-on-mac Blog index for agents: https://mole.fit/tw/blog/llms.txt Site index for agents: https://mole.fit/llms.txt