# 啟動磁碟空間幾乎已滿：找出空間到底去了哪裡

> 這則警示講的是作業餘裕，不是叫你刪檔，用 df 與 diskutil 量測，先查本機快照，再做一次結構性調整，而不是刪一堆小檔。

Published: 2026-08-09 | Updated: 2026-08-16

警示總在最不該出現的時候跳出來：你正在匯出影片、安裝更新，或是儲存文件，macOS 就打斷你，跳出 **您的啟動磁碟空間幾乎已滿**。
本能反應是打開「下載項目」開始刪。通常能清出幾個 GB，警示隔天又回來，什麼都沒學到。

macOS 是在告訴你，這個宗卷已經沒有交換、更新和暫存檔需要的作業餘裕。那些還能回收、但目前仍被釘住的空間，會計入用量，跟真實檔案沒兩樣，所以刪掉看得見的檔案，數字有時會動，有時完全不動。

**簡短答案：** 先查清楚空間去哪了，再動手刪。用 `df -h /` 查看可用空間，打開 **系統設定 > 一般 > 儲存空間**，如果你刪了一個大檔，數字幾乎沒動，空間就是被快照或可清除空間池釘住，不是你看得見的那些檔案。

## 這則警示真正在說什麼

macOS 會在啟動宗卷上留一截保留空間，用來放虛擬記憶體交換檔、系統更新時的安裝程式暫存、程式工作時寫下的暫存檔，以及 APFS 的簿記。可用空間往這截保留靠過去時，系統就會警告你。

Apple 沒有公布精確的觸發門檻，而且會隨宗卷大小、當下系統在做什麼而變。把這則警示當成餘裕不足的訊號，不要當成一個可以倒推回去的精準量測。

比數字更重要的是兩個後果：

- 磁碟空間不夠的 Mac，會先變慢，然後才會壞掉。交換檔沒地方寫，記憶體壓力就升高，系統開始猛力壓縮和分頁。
- 即使安裝程式看起來比你的可用空間小，macOS 更新仍可能拒絕安裝，因為它會先暫存一份完整副本再套用。

## 刪之前先量

從檔案系統下手，不要先看 Finder，因為 Finder 回報的空間已經把可回收池算進去了。

```
df -h /
```

在一台 1 TB 硬碟的 Mac 上，讀出來大概像這樣：

```
Filesystem        Size    Used   Avail Capacity   Mounted on
/dev/disk3s1s1   926Gi    12Gi   299Gi     4%     /
```

`Used` 欄很小，因為 `/` 是密封的系統快照，不是你的資料宗卷。`Size` 顯示 926Gi，磁碟卻標成 1 TB，是因為 `df` 用二進位 GiB 計，Apple 用十進位 GB 計。沒少東西，同一批位元組用兩種單位在描述。

要看整個容器，改問 `diskutil`：

```
diskutil info / | grep -i "Container"
```

```
   Container Total Space:     994.6 GB (994610155520 Bytes)
   Container Free Space:      321.0 GB (321045377024 Bytes)
```

現在你有一個真正的基準了。把可用空間的數字寫下來。下面每一步，都看這個數字有沒有動。

## 空間通常在哪

個人 Mac 的啟動磁碟滿了，幾乎總是下面六件事之一。照這份清單往下查，不要見最大的就刪。

| 嫌疑 | 怎麼確認 | 去哪處理 |
|---|---|---|
| 本機 Time Machine 快照 | `tmutil listlocalsnapshots /` 有列出項目 | [刪除本機快照](https://mole.fit/tw/blog/how-to-delete-local-time-machine-snapshots-mac) |
| 照片圖庫 | 通常是家目錄裡最大的單一項目 | [釋放照片儲存空間](https://mole.fit/tw/blog/how-to-free-up-photos-storage-mac) |
| iOS 裝置備份 | `~/Library/Application Support/MobileSync/Backup` | [刪除舊的 iPhone 備份](https://mole.fit/tw/blog/how-to-delete-iphone-backups-mac) |
| 郵件下載 | 郵件的帳號資料會無限增長 | [減少郵件儲存空間](https://mole.fit/tw/blog/how-to-reduce-mail-storage-mac) |
| 開發者快取 | Xcode、Docker、Homebrew、node 套件庫 | [清除開發快取](https://mole.fit/tw/blog/how-to-clear-dev-caches-mac) |
| 被忘掉的大檔 | 舊匯出、磁碟映像、下載檔 | [找出大檔](https://mole.fit/tw/blog/how-to-find-large-files-on-mac) |

macOS 會把其中好幾項併進儲存空間設定裡的 **系統資料** 分類，所以那條長條看起來又嚇人又說不清。它標的是殘餘，不是一個你能打開的資料夾；見 [系統資料到底包含什麼](https://mole.fit/tw/blog/what-is-system-data-on-mac)。

## 刪了卻騰不出空間時

就是這種情況把人趕去用清理工具。你刪了一個 20 GB 的檔案，清空垃圾桶，可用空間幾乎沒動。

常見原因是 APFS 的寫入時複製。本機 Time Machine 快照仍引用著被刪檔案佔用的區塊，檔案系統就不能釋放它們。空間會顯示成可清除，而不是可用。直接檢查：

```
tmutil listlocalsnapshots /
```

如果有列出項目，先讀 [快照指南](https://mole.fit/tw/blog/how-to-delete-local-time-machine-snapshots-mac)，別急著做別的。精簡快照往往就是全部解法，而且不會動到外接 Time Machine 磁碟上的備份。

第二個原因是 macOS 認為有些空間可以回收，因此不急著回收。真有東西需要時，它才會騰出來。這也是為什麼一台 Mac 回報的可用空間很少，卻仍能成功安裝更新。

## 儲存空間設定該用在它擅長的地方

**系統設定 > 一般 > 儲存空間** 擅長兩件事：分類長條讓你大致看出宗卷長什麼樣，建議面板則把你本來得四處找的控制項攤出來，包括自動清空垃圾桶、檢視大檔。

拿來量測就不怎麼準。分類會重疊，改完之後數字沉降得很慢，系統資料會吞掉分類器拿不準的一切。用它來定位，用 `df` 和 `diskutil` 來量。

## 不要做這些事

- **不要為了騰空間去刪 `/System`、`/Library` 或 `/private` 裡的檔案。** 在現代 macOS 上，系統宗卷是密封且唯讀的，能寫的那些部分都是承重的。
- **不要排程清空快取。** 可重建的快取馬上會回來，掃完之後每個程式第一次啟動都會變慢。見
  [哪些可以安心清除](https://mole.fit/tw/blog/how-to-clear-cache-on-mac)。
- **不要相信號稱能釋放特定數量可清除空間的工具。** 可清除空間是混雜池的上限，不是一份清單。
- **不要在 Finder 裡刪照片圖庫、郵件資料或備份資料夾** 來騰空間。用所屬的程式來處理，資料庫才會保持一致。

## 要的是穩定狀態，不是一個大數字

目標是留得住的餘裕，不是一次性衝出來的最大數字。一台舒服地待在保留空間之上的 Mac，就不會再警告你，負載下也不會開始分頁。

走到那裡通常靠一項結構性調整，而不是連刪一堆小檔：把照片圖庫或影片封存移到外接磁碟、對大型圖庫開啟「最佳化 Mac 儲存空間」，或是拿掉一套不再用的開發工具鏈。任何一項都比一下午刪截圖更耐久。

## 檢視工具該放在哪

[Mole](https://mole.fit/) 會先量再提議刪。它按真實佔用磁碟大小把宗卷攤開，在移除任何東西之前先告訴你每個候選是什麼，並且把項目移到垃圾桶而不是直接刪掉，所以選錯了還救得回來。它不會承諾一個自己證明不了的可清除數字。

## 操作順序

1. 用 `df -h /` 和 `diskutil info /` 記下可用空間。
2. 檢查 `tmutil listlocalsnapshots /`，有快照就先處理。
3. 找出真正最大的佔用者，先看家目錄，再看別處。
4. 做一項結構性調整，然後再量一次。
5. 宗卷有餘裕就停，不要等工具報出一個讓人滿意的總數。

## 常見問題

### 為什麼刪完檔案隔天警示又回來？

因為刪檔沒有改到結構。如果真正佔著的是照片圖庫、iOS 備份或一組快照，刪掉幾個 GB 的文件只會讓你剛好站在門檻之上，下一次更新或交換爆發又把你壓回去。

### Mac 該留多少可用空間？

沒有官方數字，你讀到的任何具體百分比都是某人的經驗法則，不是 Apple 規格。實務上：夠一份完整的 macOS 更新做暫存，再加上你平常工作負載下的交換空間。

### 這則警示代表磁碟快壞了嗎？

不是。它回報的是容量，跟磁碟健康無關。那是另一個問題，有另一套症狀。

### 可以不理它嗎？

一陣子可以，macOS 會靠回收可清除空間繼續運作。代價是 Mac 在記憶體壓力下變慢，更新開始失敗，所以修好它，比天天關掉警示划算。

---

Canonical HTML page: https://mole.fit/tw/blog/mac-startup-disk-full
Blog index for agents: https://mole.fit/tw/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt