兩道 fork 關卡與一道天花板

程序數量的上限由三個參數共同決定，但它們的執行時機分成兩處：其中兩個由核心在每次 fork 時檢查，第三個在 setrlimit 時把可設定的範圍壓住。

1sysctl kern.maxproc kern.maxprocperuid
2launchctl limit maxproc
3ulimit -u

一台 Apple Silicon Mac 上的實測輸出：

1kern.maxproc: 4000
2kern.maxprocperuid: 2666
3
4	maxproc     2666           4000
5
62666

fork 實際檢查的兩道是：全系統程序總數對 kern.maxproc，以及該 uid 的程序數對它自己的 RLIMIT_NPROC（soft limit，也就是 ulimit -u 讀到的那個值）。任一道不通過就回傳失敗。

kern.maxprocperuid 的執行點在第三處——setrlimit，也就是程序調整自己資源上限的那個系統呼叫（ulimit 這個 shell 指令是它的前端）。kern.maxprocperuid 規定 RLIMIT_NPROC 能被設到多高，因此它是天花板而非關卡：程序不會在 fork 的時候撞到它，而是在嘗試把自己的上限調高時被它壓住。kern.maxproc 由核心在開機時依機器規格決定，kern.maxprocperuid 在本機是前者的三分之二，目的是讓單一使用者的失控程式仍留給系統其他部分足夠的格位運作；這個比值不必記，每台機器直接讀 sysctl 就有。launchctl limit maxproc 印出的兩欄分別是 soft 與 hard limit，兩者都會被子程序繼承。

這個分工決定了調高上限的實際效果，而效果與直覺不同。把 ulimit -u 設成超過 kern.maxprocperuid 的值時，核心把它靜默壓回 2666，並且把 hard limit 一併降到 2666——而降低 hard limit 是單向不可逆的：

1python3 -c "
2import resource as r
3print('before:', r.getrlimit(r.RLIMIT_NPROC))
4r.setrlimit(r.RLIMIT_NPROC, (3000, 4000))
5print('set 3000 ->', r.getrlimit(r.RLIMIT_NPROC))
6"

1before: (2666, 4000)
2set 3000 -> (2666, 2666)

再嘗試設回 4000 會直接失敗（not allowed to raise maximum limit）——原本 4000 的 hard limit 額度就這樣消失了，恢復要重開 shell。

這裡還有一個讀數陷阱值得單獨記下。macOS 的預設 shell 是 zsh，而 zsh 的 ulimit builtin 回報的是它想設的值，不是核心實際持有的值：

1zsh:  ulimit -u 3000  ->  zsh 回報 soft=3000 hard=4000  |  核心持有 (2666, 2666)
2bash: ulimit -u 3000  ->  bash 回報 soft=2666 hard=2666  |  核心持有 (2666, 2666)

照著 zsh 的輸出判斷會得到「調高成功」的結論，而實際上限一點都沒動、hard limit 還少了三分之一。要確認核心持有什麼，讀 getrlimit 而非 shell builtin。

真正的天花板因此在 kern.maxprocperuid 這一層，調整它需要 root 權限。無論從哪一層調高，那個動作的作用都是延後撞牆的時間點，已經被佔住的格位一個都沒有因此釋放。

一般桌面使用的常駐程序數量落在幾百的量級，距離兩千多的上限有相當餘裕。當前用量可以直接量：

1echo $(( $(ps -u "$(id -un)" | wc -l) - 1 ))   # 扣掉表頭那一行

程序結束分成兩個階段

子程序呼叫 exit 的那一刻，它並沒有從程序表上消失。核心先釋放它持有的資源，再把一小塊紀錄留在原地等父程序來取——殭屍狀態就是這兩個動作之間的空檔，而觸發它們的是兩個不同的角色。

第一階段由子程序自己觸發。子程序呼叫 exit（或被信號終止）時，核心回收它的位址空間、開啟中的檔案描述子、以及其他持有的資源。這一階段結束後，這個程序已經不執行任何指令、不佔用記憶體、不排入 CPU 排程佇列。

第二階段由父程序觸發。核心在第一階段刻意保留一小塊紀錄，存放結束碼（exit status）與資源使用統計，因為父程序有權知道子程序是怎麼結束的。核心送出 SIGCHLD 通知父程序，父程序呼叫 wait() 或 waitpid() 領取這塊紀錄，核心才釋放程序表格位。這個動作在 Unix 傳統上稱為收屍（reaping）。

處於兩階段之間的程序就是殭屍（zombie）。它在 ps 的 STAT 欄位顯示為 Z，comm 欄位顯示為 <defunct>。設計良好的父程序在毫秒級內完成領取，殭屍狀態短到幾乎觀察不到；殭屍在列表裡穩定存在，代表第二階段沒有發生。

殭屍難以察覺的原因就在第一階段已經把大部分資源還回去了。它不佔使用者記憶體、不耗 CPU、沒有開啟的檔案，因此記憶體監控、CPU 監控、活動監視器的資源排行全部看不到它。它唯一消耗的是程序表格位，而程序表格位剛好就是 fork 那道 per-uid 關卡在計數的單位。一具殭屍的資源成本接近零，一千具的資源成本仍然接近零，但額度已經去掉超過三分之一。

父程序漏收的成因

第二階段沒有發生的原因集中在父程序這一側，常見的有三種。

未處理 SIGCHLD：父程序沒有安裝 handler，也沒有在主迴圈裡週期性呼叫 waitpid(-1, ..., WNOHANG)——WNOHANG 這個旗標讓呼叫在沒有子程序可收時立刻回來，因此它適合放在主迴圈裡不阻塞地掃一遍。核心送出的通知無人接收，紀錄就留著。

handler 存在但遲遲排不到執行：父程序卡在某個阻塞的系統呼叫、或主執行緒被長時間佔用，SIGCHLD 排隊等待處理。信號在傳統 Unix 語意下不排隊累積，短時間內多個子程序結束時，父程序可能只看到一次通知，若 handler 只呼叫一次 wait() 就會漏掉其餘的。正確的寫法是在 handler 內以迴圈呼叫 waitpid 直到回傳零或負值。

父程序長時間存活：這是讓漏收從瑕疵變成故障的放大條件。父程序若在幾秒內結束，殘留的殭屍會立刻被收走（機制見下節）；父程序連續執行數天甚至數週時，同樣的漏收率會線性累積成上千具。

Unix 提供一個明示放棄結束狀態的機制：父程序把 SIGCHLD 設為 SIG_IGN，核心就直接回收子程序的紀錄、不再產生殭屍。應用程式若對子程序的結束碼沒有需求，這是最省事的做法。另一個常見的迴避手法是 double-fork——fork 出中介程序，中介程序再 fork 出真正的工作程序後立即結束，工作程序因此變成孤兒、由系統的 init 程序負責收屍。這個手法有一個容易漏掉的收尾：原父程序仍要對中介程序呼叫一次 waitpid。少了這一步，中介程序自己成為殭屍，一具換一具、什麼也沒省下。

孤兒的 reparenting

父程序先於子程序結束時，子程序成為孤兒（orphan），核心把它的 ppid 改成 1，交由 launchd 接手。這個過程稱為 reparenting。

launchd 是 macOS 的 PID 1，職責之一就是對收養來的子程序持續呼叫 wait()。這決定了一個實用的性質：終止一個堆積殭屍的父程序時，它底下的所有殭屍會在同一時間被 launchd 收養並立即收屍，格位一次全數釋放。回收量等於該父程序名下的殭屍總數，不需要逐一處理。

同一個性質也解釋了為什麼短命程式很少造成問題。一個執行三秒的腳本即使完全沒有收屍邏輯，它結束時所有遺留的殭屍都會被 launchd 清掉。殭屍的堆積需要「漏收」與「父程序長存」兩個條件同時成立。

格位耗盡時的表現

可用格位耗盡時，fork 回傳 EAGAIN。在 macOS 上這個錯誤碼是 35，對應訊息字串為 Resource temporarily unavailable：

1python3 -c "import errno, os; print(errno.EAGAIN, os.strerror(errno.EAGAIN))"

135 Resource temporarily unavailable

錯誤碼的數值跨系統不同，這點會影響查表方向：Linux 的 EAGAIN 是 11，macOS 沿用 BSD 的 35。看到 os error 35 這串字時要對照的是 macOS 的表，用 Linux 的表查會得到 EDEADLK——而它的訊息字串是 Resource deadlock avoided，與 macOS 的 Resource temporarily unavailable 形狀相近、讀起來同樣像是「某項資源暫時有狀況」。查錯表的人因此不會察覺自己查錯了，而是被推去追鎖與死結。

額度見底之後，最先有反應的是那些每分鐘要開幾十次新程序的元件，而這個先後順序具有誤導性。已經在執行的常駐程序完全不受影響——瀏覽器、編輯器、正在跑的伺服器都照常運作，因為它們早就佔好了自己的格位。最先失敗的是高頻建立短命程序的元件：

shell prompt 的狀態查詢：像 gitstatusd 這類每次按下 enter 就查一次 repo 狀態的元件，每次都要 fork。

多層 shebang 的腳本：#!/usr/bin/env -S uv run --script 這種寫法執行一次會疊起兩個並存的程序——直譯器管理工具，加上它開出來的直譯器本身。（env 不算在內：它用 execve 把自己替換掉，不多佔一格。）剩餘額度只有十來個時，同時要拿到兩格的呼叫是最先失敗的一批。

建置與測試工具鏈：編譯器、測試框架、任何會平行開子程序的工具。

失敗集中在這些元件上，容易讓人以為是該元件本身出了問題。判準是：失敗的操作彼此在功能上沒有關聯，唯一的共同點是都需要新開程序。符合這個形狀時，先量格位。

診斷順序

診斷用三個固定成本的查詢完成，每一步的輸出直接決定下一步，中間不需要推測。

先提一件反直覺的事：這些指令自己也要 fork。ps | sort | uniq -c 這種管線一次要開三到四個程序，而執行它的時機正好是格位最緊的時候。額度已經見底到指令跑不起來時，順序要倒過來——先從候選集裡關掉一個最大的常駐程式（模擬器、虛擬機），把格位騰出來，再回頭做診斷。關掉的那個若正好是元凶，殭屍會一併消失，這本身就是答案。

第一步量總額，確認格位確實見底：

1echo $(( $(ps -u "$(id -un)" | wc -l) - 1 ))   # 目前程序數
2ulimit -u                                       # 上限

第二步分類，判斷佔額度的是活程序還是殭屍：

1ps -u "$(id -un)" -o stat | grep -c '^Z'

範圍要限定在同一個 uid。配額是 per-uid 的，而 ps -eo stat 掃的是全系統——兩個數字並置比較時基準不同，會把別的使用者（含系統服務）的殭屍算進自己的帳上。

殭屍數若接近第一步的總數，方向就確定了。殭屍數接近零而總數仍逼近上限時，代表確實有那麼多活程序在跑，這時改依執行檔聚合，看是哪一支開出了幾百份：

1ps -u "$(id -un)" -o comm | sort | uniq -c | sort -rn | head -10

正常的機器上這份清單的頭幾名是 shell、瀏覽器的 renderer、編輯器的 language server，數量落在數十。某一支衝到三位數就是那條線索——常見的是重複啟動的開發伺服器（每次熱重載留下一份舊的）、平行度設定過高的測試套件，或退出時沒有清乾淨的容器。

第三步指認父程序，把所有殭屍依 ppid 聚合：

1ps -u "$(id -un)" -o ppid,stat,comm | awk '$2 ~ /^Z/ {print $1}' | sort | uniq -c | sort -rn | head -5

輸出的每一行是「殭屍數量 + 父程序 PID」。一台已經撞到上限的機器上，這行指令的輸出可能只有一行：

12008 89668

聚合結果集中在單一 PID 時，父程序已經確定，剩下的只有查它的身分：

1ps -o pid,ppid,etime,command -p <ppid>

一個實測例子的輸出：

1  PID  PPID     ELAPSED COMMAND
289668     1 10-05:12:33 qemu-system-aarch64 -netdelay none -netspeed full -avd Medium_Tablet_2

ELAPSED 欄位讀作十天五小時十二分，這個數字補上了時間維度：殭屍是十天內線性長出來的，跟查詢當天執行了什麼操作沒有關係，只是當天正好跨過上限那條線。累積型故障的共同特徵就是發作時機與觸發原因在時間上完全脫鉤，ELAPSED 是把兩者接回去的欄位。

ppid 聚合值得排在任何因果推測之前，理由是成本結構：它是一行指令的定值查詢，直接指認父程序，不依賴關於「誰在耗資源」的任何假設。當一個定值查詢能取代一串推論時，先跑查詢。

這條順序有一個超出 macOS 的理由。本文案例裡的模擬器十天內 fork 了兩千多次、平均每小時八次，遠少於 hook 的呼叫頻率——它之所以能吃掉四分之三的額度，是因為這兩千多次沒有一次歸還。佔用量是申請頻率乘上持有時間，而申請頻率的差距以倍數計、持有時間的跨度沒有上界，於是佔用量的排序由持有時間主導，報錯的位置卻只跟申請頻率有關。檔案描述子、連線池、鎖與 rate limit 額度上都存在同一組落差，跨資源的歸因順序與判讀徵兆整理在 #252 配額耗盡的症狀落在申請最頻繁的元件、成因在持有最久的那個。

回收格位的手段

要拿回那些格位，動作全部落在父程序身上——殭屍自己已經沒有可以被操作的部分。對殭屍本身送信號沒有作用——信號的生效前提是接收方會再被排程執行一次，而殭屍在第一階段就已經停止執行，kill -9 送出後沒有任何指令會因此被執行。

催父程序去領：

1kill -CHLD <parent-pid>

這會補送一次 SIGCHLD。父程序若有 handler 但錯過了先前的通知，可能因此開始回收。父程序沒有安裝 handler、或卡在阻塞呼叫時，這一步沒有反應，成本是一行指令，值得先試。

終止父程序：

1kill <parent-pid>          # 先給正常關閉的機會
2kill -9 <parent-pid>       # 未退出時再強制

父程序結束後，reparenting 讓 launchd 一次收完所有殭屍。這是回收量最大、也最確定的手段。父程序是有使用者介面的應用程式時（模擬器、虛擬機、開發工具），從介面正常關閉的效果相同，且能讓它完成自己的清理流程。

重新開機同樣有效，但它是「終止父程序」的高成本超集。三步診斷已經指認出父程序的情況下，重開機只是把附帶損失擴大到整台機器。

哪類程式會累積殭屍

會累積殭屍的程式有一組共同特徵：長時間常駐、且在生命週期內反覆建立子程序而沒有確實收屍。這組描述對應前面那兩個必要條件——後半句是「漏收」，前半句是「父程序長存」；反覆建立子程序本身只是讓漏收有機會反覆發生，正確收屍的程式同樣頻繁 fork、而格位用完就還。前面那個 qemu 就是這個形狀的典型：模擬器為了周邊功能反覆開子程序，而它被設計成開著就不關。同一個形狀在開發環境裡還有幾個常見的落點——開發伺服器與檔案監看器、language server、長跑的容器 runtime，共同處境都是「本來就設計成一直開著」，於是再低的漏收率也終究會累積到上限。

日常檢查的成本是一行指令。寫成只在超線時才輸出，就可以掛進週期任務或 shell 啟動檔——門檻要能主動找上人，否則它只是事後判讀的參考值，而事後才去量的時候故障已經發生了：

1z=$(ps -u "$(id -un)" -o stat | grep -c '^Z'); p=$(( $(ps -u "$(id -un)" | wc -l) - 1 )); l=$(ulimit -u)
2[ $z -gt $((l/100)) ] || [ $p -gt $((l*7/10)) ] && echo "procs $p/$l, zombies $z"

判讀門檻用比值寫、不用絕對數，因為上限隨機器規格變動（本機 2666，別台機器可能是別的數）。兩條參考線：

殭屍數超過上限的百分之一（本機約 27 具）就值得去找父程序是誰。個位數的殭屍是正常的瞬時狀態——父程序還沒輪到處理 SIGCHLD；累積到這個量級代表某個父程序的回收邏輯有缺陷，而它會繼續累積下去。這條線的依據是「正常狀態的殭屍數不隨時間成長」，因此門檻設在哪都行，只要它明顯高於瞬時波動。

第二條線看總數：上限的七成（本機 1866）。這條線刻意留得寬，而且它沒有精確的推導——剩下的三成在本機是 800 格，遠多於一次建置或一輪測試所需的數十到上百個短命程序。寬是有理由的：撞到這條線的代價只是提早查一次，而撞到真正上限的代價是建置中斷、測試莫名其妙掛掉，且那些失敗不會說出自己是資源不足。

要把這條線收窄成有依據的值，在自己最重的工作型態下量一次峰值即可——建置或測試跑到最忙時讀一次 ps -u "$(id -un)" | wc -l，把那個讀數當作必須保留的餘裕。平行度開得高的測試套件、本機同時跑好幾個容器、或一邊編譯一邊跑模擬器，量出來的峰值都會比上面那個範圍大。

操作面最有效的預防是把用完的模擬器與虛擬機關掉。長跑的 Android 模擬器另有一組完全不同的表現層症狀——半活狀態會讓 flutter devices 掛在 device property 查詢上，判讀訊號與恢復順序見 flutter devices 卡住的訊號。兩者的來源同屬長跑程序，但一個表現為單一工具的查詢逾時，一個表現為全使用者範圍的 fork 失敗。

模擬器與虛擬機同時也是磁碟空間的大戶，常駐成本在空間與程序表兩邊各記一筆，磁碟側的排查流程見 磁碟空間診斷流程。

為什麼是 BSD、而且是舊的 GNU

macOS 的 Unix 底子（Darwin）來自 BSD，所以內建的命令列工具是 BSD 版，語意跟旗標跟著 BSD。至於 GNU 版本的工具，Apple 刻意停在舊版：GNU 的 coreutils、bash 等專案在某個時點把授權從 GPLv2 改成 GPLv3，而 GPLv3 的專利條款與反 Tivoization 條款（禁止廠商鎖死硬體、不准跑使用者修改過的軟體）是 Apple 不接受的，於是 Apple 把系統內建的 GNU 工具凍在最後一版 GPLv2、之後不再更新，整體改倚重 BSD 與自家工具。/bin/bash 停在 3.2（2006 年的版本、最後的 GPLv2）就是這個決定最顯眼的標記。

結論是：macOS 給你的是「BSD userland + 一套凍結在多年前的舊 GNU」。這不是缺陷或沒維護，是授權取捨下的刻意設計。知道成因，下面三種現象就都是可預期的。

形態一：工具根本不在

GNU-only 的工具在 macOS 預設沒有，呼叫直接 command not found。最常撞的是 timeout（GNU coreutils 的一員）——一支在 Linux 用 timeout 60 some-cmd 包起來的腳本，搬到 macOS 第一步就掛。

判讀很直接：一個在 Linux 上理所當然的指令，在 macOS 回 command not found，先問「它是不是 GNU coreutils / GNU-only 的東西」。是的話，macOS 本來就沒有，要嘛裝（見下方對策）、要嘛換不依賴它的寫法。

形態二：同名、行為不同（最陰險）

比「工具不在」更難抓的是工具名一樣、但 BSD 版的旗標或語意跟 GNU 版不同——它不報錯，默默做出不一樣的結果。幾個天天會用到的：

• sed -i：BSD 版的 -i 後面必須接一個備份檔後綴（sed -i '' 's/a/b/' file 那個空字串就是「不留備份」）；GNU 版的 -i 直接就地改、不接參數。把 GNU 寫法 sed -i 's/a/b/' file 搬到 BSD，sed 會把 s/a/b/ 當成備份後綴、把 file 當成 script，行為全錯。
• readlink -f：解析符號連結的最終絕對路徑，GNU 有這個旗標，BSD 版長年沒有（macOS 較新版本才補上）。可攜的替代是 realpath，或退回不依賴它的方式。
• date：算日期時間 GNU 用 date -d '...'、BSD 用 date -v（相對）或 date -j（指定），旗標完全不同，照抄必錯。
• getopt / stat / grep -P / find：getopt BSD 版不支援長選項（--foo）、GNU / util-linux 版才支援，靠它解析長參數的腳本在 macOS 整個失效；stat 的格式旗標 GNU 是 -c、BSD 是 -f；grep -P（PCRE）GNU 有、BSD 沒有；find / xargs 也有零星旗標差異。

跨平台腳本在 macOS 上結果怪、卻一個錯誤訊息都沒有時，先回頭盤點它用了哪些 BSD/GNU 行為分歧的指令（sed、date、stat、grep）。這一類的特徵正是不報錯、只默默做出不一樣的結果——比形態一的 command not found 難抓，因為沒有紅字提醒你哪裡不對。

形態三：bash 太舊，而且預設 shell 已換

/bin/bash 凍在 3.2，所以 bash 4 以後才有的語法在 macOS 的系統 bash 上全部不存在：關聯陣列（declare -A）、${var,,} / ${var^^} 大小寫轉換、readarray / mapfile、|&。一支 #!/bin/bash 又用了這些的腳本，在 macOS 會直接語法錯。

另外 macOS 的預設互動 shell 已經是 zsh（從 Catalina 起），bash 要自己裝。所以「假設使用者的 shell 是 bash」這件事在 macOS 也不成立。

還有一個跟這個舊 bash 直接相關的細節：在 UTF-8 locale 下，bash 3.2 的多位元組解析不夠健全，shell 變數 $var 後面若緊跟一個多位元組字（例如中文全形括號），它可能把該字的首位元組吞進變數名、報 unbound（實測 macOS 3.2；C / POSIX locale 反而不會——那些按單位元組解析、變數名正好斷在 $var）。寫法上一律用 ${var} 把變數名邊界標清楚就免疫，跟 locale 與 bash 版本無關。

對策與取捨

三條路，依「這支腳本要給誰跑」選：

• 裝 GNU 工具（自己的互動環境）：brew install coreutils gnu-sed findutils grep gawk bash。這些 formula 各自裝 g-prefix 版、刻意不覆蓋 BSD 原生（coreutils 給 gtimeout / greadlink / gdate、gnu-sed 給 gsed、依此類推）——不覆蓋是因為系統與其他軟體可能依賴 BSD 行為，蓋掉會讓那些元件出錯。要讓無前綴的名字也走 GNU 版，把 $(brew --prefix)/opt/coreutils/libexec/gnubin 加進 PATH（那裡有無前綴 symlink 指向 GNU 版；但這只涵蓋 coreutils 那批，sed / grep / find / awk 要各自加它們對應的 gnubin）。這條 PATH 讓你的 shell 跟系統其他部分的 BSD 假設分歧，所以它屬於「自己的互動環境」這格、別設成全域（具體會怎麼壞：有些 configure / autotools 腳本靠 sed --version 之類的字串判斷手上的 sed 是 GNU 還是 BSD、據此決定加哪些旗標，PATH 被 gnubin 覆蓋後這個判斷跟系統其他部分的預期不一致，可能在編譯期出岔）。新 bash 裝到 $(brew --prefix)/bin/bash（brew --prefix 在 Apple Silicon 是 /opt/homebrew、Intel 是 /usr/local），腳本要用 #!/usr/bin/env bash（走 PATH）才抓得到它，#!/bin/bash 仍是系統的 3.2。
• 只寫 POSIX 子集（要兩邊都跑的腳本）：避開所有 GNU-ism——sed -i 改用 tmp 檔加 mv、不用 readlink -f（用 realpath 或 cd && pwd）、不用關聯陣列。最可攜、macOS / Linux / BSD 都動，代價是放棄 GNU 的便利語法。bootstrap 腳本、CI 腳本適用。
• 偵測分支（有就用、沒有就退化）：command -v gtimeout >/dev/null && T=gtimeout || { command -v timeout >/dev/null && T=timeout || T=""; }，用 $T 呼叫、空的就略過那層保護。給「這個工具是加分、缺了不致命」的用法。

判準是：自己天天用的互動環境，裝 gnubin 圖方便沒問題；但要交付給別人或 CI 跑的腳本，不能假設對方裝了 GNU 工具——那種要嘛 POSIX 子集、要嘛偵測分支。這裡有個容易誤判的中間情境：你自己寫的 dotfiles / bootstrap 腳本歸「交付」那格、不是「互動環境」那格。它主觀是「自己用」，客觀上交付的對象包含換機器時的未來自己與團隊，而且執行時機常早於互動環境成形——bootstrap 腳本自己負責裝 coreutils，跑到它自己用 sed / timeout 那行時 PATH 裡根本還沒有 gnubin（先有雞）。把「我的機器剛好裝了 coreutils」當成腳本的前提，就是這篇一開始那些跨平台故障的來源。

（第四條路是跳出 shell：碰到 BSD/GNU 差異密集的邏輯，乾脆用 Python 之類的語言寫，讓問題不落在會撞差異的那一層。本文停在 shell 內談，是因為定位在「教 BSD vs GNU 這個機制」；真要選型換語言是另一個決策。）

下一步路由

• 一台新 Mac 從開箱到能開發、Homebrew / bash / 個人 bin 的設定順序：新機基礎建設
• 跨 Linux 發行版與 macOS 的工具名、存在性、版本節奏分歧全景：平台與發行版差異的判讀地圖
• 寫跨平台 bootstrap 腳本時「別硬編你這台剛好有的東西」（權限、工具、locale）：bootstrap 腳本的骨架與套件清單

執行機制

Apple Silicon 的 CPU 架構（arm64）跟 iPhone/iPad 相同，所以 iOS App 的二進位可以直接在 Mac 上跑，不需要轉譯或模擬。macOS 提供一個相容層，把 iOS 的觸控 API 對應到滑鼠和鍵盤操作，讓 iOS App 在 Mac 上有基本的操作體驗。這個相容層跟 Mac Catalyst（開發者主動移植 iPad App 到 Mac 的框架）是不同的機制——iOS App on Mac 不需要開發者做任何修改。

這跟 iOS Simulator 是完全不同的機制。Simulator 跑的是為 Mac CPU 重新編譯的 iOS 框架，用於開發測試；iOS App on Mac 跑的是 App Store 上為 iPhone 編譯的原始二進位，用於日常使用。

Container 用 UUID 命名

原生 Mac App 的 沙箱容器 用 bundle ID 當目錄名（例如 com.amazon.Lassen）。iOS App on Mac 的容器用 UUID 當目錄名（例如 D678BD0C-AEB0-4E05-B0D2-58F5C45F0207），從名字完全看不出是哪個 App。

UUID 命名的原因是 iOS App 的容器管理走的是 iOS 的路徑——iOS 上本來就用 UUID 組織 App 資料，macOS 的相容層沿用了這個設計。

辨識 UUID 容器的方法是讀 .com.apple.containermanagerd.metadata.plist 裡的 MCMMetadataIdentifier 欄位，需要 Full Disk Access 權限。操作流程見 辨識 App 容器。

遊戲是主要的空間消耗者

iOS App on Mac 裡佔用最大的幾乎都是遊戲。手遊的語音包、素材、更新包動輒數 GB，這些資源下載到 Container 的 Data/Documents/ 裡。一台 256G Apple Silicon Mac 上的實際案例：

• Epic Seven（第七史詩，com.stove.epic7.ios）：9.7G
• Arknights（明日方舟台服，tw.txwy.ios.arknights）：8.7G

這些資源是可重新下載的衍生物，帳號進度在遊戲伺服器端。刪除本地容器不影響帳號，重裝時需要重新下載資源。

空間佔用在 Data 卷上

iOS App on Mac 的容器跟所有 App 資料一樣，儲存在 APFS container 的 Data 卷上，共用空間池。遊戲類 App 的容器動輒數 GB，直接壓縮 Data 卷的可用空間。

不出現在 /Applications

iOS App on Mac 不一定出現在 /Applications 資料夾或 Finder 的應用程式列表裡。它們的 .app 本體放在系統管理的位置（通常在 /Applications 的子目錄或 App Store 的快取路徑），Launchpad 能看到但 Finder 的應用程式資料夾不一定列出。

用 du -shx /Applications/*.app 排查空間大戶時會完全漏掉 iOS App。它們的空間佔用只出現在 ~/Library/Containers/ 裡，而且因為 UUID 命名，不展開辨識就不知道是哪個 App。

移除後容器可能殘留

從 Launchpad 長按刪除或從 App Store「已購項目」移除 iOS App 後，它的 Container 目錄不一定跟著消失。macOS 的清理機制有時會延遲或跳過。殘留的 Container 佔用空間但不再有對應的 App。

確認殘留的方式：Container 的 plist 裡有 MCMMetadataIdentifier（bundle ID），但系統裡找不到對應的已安裝 App。這時整個 Container 目錄可以安全刪除。

已下架 App 的風險

iOS App Store 裡的 App 可能被開發者下架或因區域限制無法取得。如果一個 iOS App on Mac 已經從 App Store 移除，刪掉本地容器和 App 後就無法重新安裝。對於有替代品的 App 影響不大；對於特定地區限定的遊戲（例如只在日本或台灣 App Store 上架的版本），刪除前要考慮這個不可逆性。

一組 Runtime 的組成

一組 runtime 的體積幾乎全部來自兩個 DMG（disk image）——Bundle 和 Runtime 各承擔不同的職責。

Bundle DMG（約 8G）：包含 Simulator 的 Cryptex 安全元件和啟動資料。儲存在 /Library/Developer/CoreSimulator/Cryptex/Images/bundle/ 下。

Runtime DMG（約 8G）：包含完整的 iOS 檔案系統——所有系統框架、內建 App、字型、語言資源。儲存在 /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/ 下。

兩個 DMG 合起來約 16G，是一組 runtime 的完整大小。

1# 查看已安裝的 runtime 和總大小
2xcrun simctl runtime list

1== Disk Images ==
2-- iOS --
3iOS 18.3.1 (22D8075) - 07012283-CA3D-4437-8A5F-89AE5346EEED (Ready)
4
5Total Disk Images: 1 (8.1G)

simctl runtime list 報的 8.1G 是 Runtime DMG 的大小，沒有包含 Bundle DMG。完整佔用要兩者相加。

DMG 掛載成獨立 APFS Container

使用 Simulator 時，macOS 把這兩個 DMG 掛載成獨立的 APFS Container。diskutil list 會看到它們以 (disk image) 標示：

1/dev/disk4 (disk image):    →  iOS 18.3.1 Simulator Bundle    9.0 GB
2/dev/disk6 (disk image):    →  iOS 18.3.1 Simulator           19.8 GB

這些 Container 的 Physical Store 是 DMG 檔案本身——實際的磁碟空間消耗在主 Container（disk3）的 Data 卷上。刪除 runtime 回收的空間會反映在 Data 卷的可用空間，而不是讓這些 disk image Container 消失（它們會自動卸載）。

Container 顯示的大小（9.0G、19.8G）是 DMG 內部的邏輯容量，比 DMG 檔案的實際磁碟佔用（各約 8G）略大，因為檔案系統有自己的 metadata 開銷。判斷空間佔用時看 DMG 檔案的 du 值，不看 Container 的 Size。

為什麼每組要 16G

iOS Simulator 是完整的 iOS 使用者空間環境——App 在 Simulator 上跑時，呼叫的是真正的 iOS 系統框架（UIKit、Foundation、SwiftUI），這些框架需要完整打包在 runtime 裡。Simulator 跑的是 x86_64 或 arm64 原生碼（Apple Silicon Mac 上是 arm64），所以框架二進位跟實體裝置上的不同，必須另外編譯一套。

16G 裡大約的分佈：

• 系統框架和 dyld shared cache：佔最大宗，包含所有 iOS 框架的預連結版本
• 內建 App（Safari、設定、照片等）：Simulator 需要完整的系統環境
• 多語言資源：字型、語言包、輔助使用資源
• Cryptex 安全元件：跟 macOS 的 Cryptex 機制類似（見 Preboot 卷），讓 Simulator 的安全元件可以獨立更新

相鄰版本（如 18.2 和 18.3.1）共用大部分內容，但 Apple 目前不做跨版本 delta 壓縮——每組 runtime 是完整獨立的。這是為什麼裝兩組就是 32G、三組就是 48G，線性增長。

裝幾組合理

判準是開發工作實際需要測試的 iOS 版本數量：

一組（最新版）：適合多數開發者。Flutter 和 SwiftUI 開發通常只需要在最新 iOS 上測試，舊版相容性問題靠 API availability check 處理，不需要實際跑 Simulator。

兩組（最新 + 上一個大版本）：App 的 deployment target 設在上一個大版本（例如 iOS 17）時，需要在該版本上跑 UI 測試確認佈局和行為。

三組以上：企業 App 支援更舊的 iOS 版本，或需要測試跨版本升級行為。這種情況下空間成本是已知的取捨。

不確定時，先裝最新版，需要舊版時再下載——Xcode 會在建置或開啟 Simulator 時提示，下載約需 30 分鐘（視網路速度）。

跟磁碟空間排查的關係

Simulator runtime 的空間佔用有兩個特徵讓它在排查時容易被忽略：

1. DMG 檔案不在家目錄下：du -shx ~/* 不會掃到它們，因為 DMG 儲存在 /System/Library/AssetsV2/ 和 /Library/Developer/CoreSimulator/。家目錄層的排查會完全漏掉這塊。

2. 掛載後的 Container 看起來像獨立磁碟：diskutil apfs list 列出的 Simulator Container 容易被誤認為是獨立的磁碟空間佔用，但它們的 Physical Store 是 Data 卷上的 DMG 檔案。理解 APFS 的 Container/Physical Store 關係（見 APFS 卷結構）後，這個混淆就消除了。

disk-report 腳本的完整診斷模式會列出已安裝的 Simulator runtime，多版本時標記 redundant。移除多餘版本的操作流程見 移除多餘 iOS Simulator。

三層架構：Physical Store → Container → Volume

APFS 把一顆實體磁碟組織成三層：

Physical Store 是實體磁碟上的一個分割區。一台 Mac 的內建 SSD 通常有三個分割區：ISC（iBoot System Container，約 500MB，安全啟動用）、主分割區（幾乎佔滿整顆磁碟）、Recovery（約 5G）。主分割區裝載一個 APFS Container。

Container（APFS Container，磁碟空間管理單位，跟 App Sandbox 的 Container 是不同層級的概念）是空間管理的最上層單位。它從 Physical Store 拿到一塊空間，再分配給底下的 Volume。關鍵設計是：Container 裡的所有 Volume 共用同一個空間池，沒有預先劃分的配額。任何一個 Volume 都能用到整個 Container 的剩餘空間，但任何一個 Volume 膨脹也會壓縮其他 Volume 的可用空間。

1# 查看 Container 的空間分配
2diskutil apfs list

這台機器的 Container disk3 有 245.1GB，底下五個 Volume 共用這個池：

1Container disk3 (245.1 GB)
2├── Macintosh HD    (System)   11.2 GB  — 唯讀系統卷，sealed
3├── Preboot                    8.5 GB  — 開機前置資料 + [Cryptex](../macos_preboot_volume_check/)（安全更新元件）
4├── Recovery                   2.2 GB  — 復原模式
5├── Data                     207.7 GB  — 使用者資料，日常操作都在這
6└── VM                         6.5 GB  — 虛擬記憶體 swap
7                          剩餘  8.9 GB  — Container 未分配空間

Volume 是檔案系統的操作單位——目錄、檔案、權限都在這層。每個 Volume 有自己的 Role（System、Data、Preboot、Recovery、VM），決定它的用途和掛載方式。

Volume Group：System 跟 Data 的綁定關係

macOS 把 System 卷和 Data 卷綁成一個 Volume Group。System 卷是唯讀的（sealed），放作業系統本體；Data 卷放使用者資料。開機時系統把兩者疊在一起，使用者看到的 / 是 System 卷的內容，/Users、/Applications 等路徑透過 firmlink（APFS 特有的雙向連結，讓兩個卷的目錄看起來像同一棵樹）指向 Data 卷。

1# 確認 Volume Group
2diskutil info /System/Volumes/Data | grep "APFS Volume Group"

Volume Group UUID 在排查 Preboot 時很重要——Preboot 卷裡的開機資料是按 Volume Group UUID 組織的，一個 UUID 對應一套完整的開機資料。正常情況只有一個 UUID（見 Preboot 卷）。

空間池對排查的影響

共用空間池意味著不能把「各 Volume 的 Capacity Consumed 加起來」當成已用空間——因為 APFS 有 clone（多個檔案共用底層資料區塊）和 snapshot（時間點凍結），這些機制讓「屬於 Volume A 的區塊」和「屬於 Volume B 的區塊」之間有共用關係。

判斷「還剩多少可用空間」要看 Container 層的 Capacity Not Allocated，這是扣除所有 Volume 和 snapshot 的實際佔用後的真正剩餘：

1# Container 層的未分配空間（真正的剩餘）
2diskutil apfs list | grep -A5 "Container disk3" | grep "Capacity Not Allocated"

df -h / 或 df -h /System/Volumes/Data 顯示的 Available 也反映 Container 層的可用空間，但呈現方式不同——df 把整個 Container 的可用空間都算成 Data 卷的可用，因為 Data 卷可以用到池裡的任何剩餘空間。

du、df、diskutil 數字不同的原因

三個工具看磁碟空間的視角不同，數字各有適用場景：

差異在 APFS clone。Clone 讓多個檔案共用同一份底層資料區塊——修改其中一個時才複製被改的區塊（copy-on-write）。du 逐檔計算，每個 clone 各算一次；diskutil 看 Volume 層的實際區塊佔用，共用的只算一次。

這就是為什麼用 du 量 Preboot 卷會得到比 diskutil info 更大的數字（見 Preboot 卷）——Preboot 裡的 os.dmg 和 os.clone.dmg 是 APFS clone，du 把兩個檔案各算一次報約 11G，但 diskutil 看實際區塊佔用只有約 5.4G（單一 os.dmg 的大小），整個 Preboot 卷的 diskutil 佔用是 8.5G（含其他開機資料）。

Sparse 檔案是另一個差異來源。Sparse 檔案宣告了一個邏輯大小，但只有寫入過的區塊才真正佔磁碟。ls -l 和 find -size 看的是邏輯大小，du 看的是實際佔用。容器映像（OrbStack、VM 磁碟映像）常是 sparse 檔，邏輯大小可能是實際佔用的數十倍。排查空間大戶時一律用 du，不信 ls 的數字。

額外的 Container：iOS Simulator

iOS Simulator runtime 以 disk image（DMG）形式儲存在 Data 卷上，開機或使用時掛載成獨立的 APFS Container。這些 Container 出現在 diskutil apfs list 裡，看起來像是佔了額外的磁碟空間，但它們的 Physical Store 是 disk image 檔案——實際空間消耗在 Data 卷上，不是獨立的實體分割區。

1# Simulator 的 disk image Container
2diskutil list | grep "disk image"

刪除 Simulator runtime 回收的空間會反映在 Data 卷（和 Container 的未分配空間），而不是讓某個 Container 消失。詳見 iOS Simulator runtime 架構。

沙箱的設計目的

App Sandbox 限制每個 App 只能存取自己的資料，不能碰其他 App 或使用者的檔案。這個隔離不是建議性的——沙箱由作業系統核心強制執行，App 程式碼裡寫了讀取其他 App 目錄的路徑，系統會拒絕。

Mac App Store 上架的 App 必須啟用沙箱。非 App Store 分發的 App 可以選擇不啟用，但越來越多開發者主動啟用以獲得使用者信任。

每個沙箱 App 拿到的是一個完整的家目錄副本——裡面有 Documents、Library、Downloads 等跟使用者家目錄一樣的子目錄，但 App 看到的路徑是自己的副本，不是使用者真正的家目錄。這些副本就放在 ~/Library/Containers/<bundle-id>/Data/ 下。

Container 的內部結構

每個 Container 的結構是固定的：

 1~/Library/Containers/<bundle-id>/
 2├── .com.apple.containermanagerd.metadata.plist  # 容器 metadata
 3└── Data/
 4    ├── Documents/      # App 的文件（使用者資料）
 5    ├── Library/        # App 的 Library（設定、快取、資料庫）
 6    │   ├── Caches/     # 快取（可安全清除）
 7    │   ├── Preferences/# 設定
 8    │   └── ...
 9    ├── Downloads/      # 有的是 symlink 到使用者的 ~/Downloads
10    ├── Desktop/        # 通常是 symlink
11    ├── tmp/            # 暫存
12    └── StoreKit/       # App Store 相關

Downloads、Desktop、Movies、Music、Pictures 多數是 symlink（符號連結）指向使用者的對應目錄——沙箱允許 App 透過使用者授權存取這些位置。du 加 -x 旗標時不會跨越 symlink 計入，所以不會重複計算。

命名慣例：bundle ID vs UUID

Container 目錄的命名方式取決於 App 的來源。

Bundle ID（App 的唯一識別碼，格式為反向域名，例如 com.amazon.Lassen）：Mac 原生 App 使用 bundle ID 當目錄名。從名字就能辨識——com.amazon 是 Amazon、com.docker.docker 是 Docker。

UUID（例如 D678BD0C-AEB0-4E05-B0D2-58F5C45F0207）：iOS App on Mac 使用 UUID 當目錄名，從名字完全無法辨識是哪個 App。辨識方法是讀 Container 根部的 .com.apple.containermanagerd.metadata.plist（見 辨識 App 容器）。

佔用的兩類：快取 vs 資料

清理 Container 時要判斷佔用的性質——快取刪了會自動重建，資料刪了就消失。

快取類（Data/Library/Caches/、Data/tmp/）：App 產生的衍生物，刪除後 App 自動重建。清除零風險，最多讓 App 下次啟動慢一點或需要重新登入。

資料類（Data/Documents/、Data/Library/Application Support/）：使用者資料——遊戲的下載資源、電子書的離線書庫、聊天紀錄、筆記資料庫。刪除後資料消失，要從雲端重新下載（如果有雲端同步的話）。

兩類的大小比例因 App 而異。遊戲類 App 的 Documents 常佔 90% 以上（語音包、素材、更新包），快取比例很低。瀏覽器類 App 則相反，快取常佔大宗。排查時逐 App 看 Data/Documents 和 Data/Library/Caches 的大小分佈，才能判斷清掉能回收多少、風險是什麼。

跟 Application Support 的分工

沙箱 App 的資料全部在自己的 Container 裡。非沙箱 App 的資料則散在 ~/Library 的公共位置——Application Support、Caches、Preferences 等。同一個開發商的 App 可能有些啟用沙箱（Container 裡一份完整資料）、有些沒有（散在公共位置），兩者的佔用要分開看。

App 聚合佔用報告 的 app-report 腳本把 Container 和公共位置的佔用聚合回各 App，就是處理這個分散的問題。

Group Containers

~/Library/Group Containers/ 是同一個開發商旗下多個 App 共享資料的位置。目錄名前面多一段 team ID（10 碼英數，像 HUAQ24HBR6.dev.orbstack）。清理時要注意：動一個 Group Container 可能影響同廠商的多個 App。

Preboot 在開機流程中的角色

Preboot 是 APFS container 裡的五個卷之一，專門存放開機前置資料——開機載入器、核心快取、安全驗證票證。這些東西必須在 Data 卷解鎖之前就能讀取，所以放在獨立的卷裡。所有卷共用同一個空間池，Preboot 佔多少 Data 就少多少。

Intel Mac 的 Preboot：簡單的開機載入器

在 Intel Mac 上，Preboot 的內容很單純：一組 boot.efi（EFI 開機載入器）、少量開機設定、以及 FileVault 解鎖介面的資源。這些加起來通常只有 1-2G，而且幾乎不會變動——裝完系統後大小就固定了，不會隨使用時間膨脹。

這個時期建立的經驗是：Preboot 應該很小，超過幾 GB 就是有問題。

Apple Silicon 的 Preboot：Cryptex 改變了容量結構

Apple Silicon Mac 從 macOS 13 開始引入 Cryptex（Cryptographically Sealed Extension），Preboot 的內容和大小因此完全改變。

Cryptex 解決的問題是安全更新的部署速度。在 Cryptex 之前，修一個 Safari 漏洞需要推一整版 macOS 更新——整個系統卷要重新驗證、重新封印。Cryptex 把 Safari 和系統安全元件從系統卷抽出來，封裝成獨立的簽章 DMG，放在 Preboot 卷裡。開機時系統把 Cryptex DMG 掛載、疊加到系統卷上層，效果等同於系統卷的一部分，但更新時只要替換這個 DMG，不動系統卷本體。

這個設計的代價是 Preboot 的體積。一組 Cryptex 的 os.dmg 約 5.4G，是 Preboot 佔用的主力。加上 restore 開機復原資料（約 800M-1G）、各機型的 kernelcache（每個約 30M，十幾個機型合計數百 MB）、以及 boot 載入器（約 50M），Apple Silicon 的 Preboot 基本盤就在 6-8G 左右。

restore-staged：更新機制的暫存區

Preboot 裡還有一個 restore-staged 目錄，是系統更新機制的暫存區。macOS 會在背景下載更新資料（韌體映像、加密的 DMG、核心快取），先 staging 到這裡，等使用者同意安裝或自動維護窗口到來時才套用。

這個目錄的大小在 0-2G 之間浮動，取決於是否有待套用的更新。它的內容不一定對應「當前版本的下一版」——一台 macOS 15.3.1 機器上的實測中，restore-staged 裡的 RestoreVersion.plist 顯示的版本號是 26.3.1（這是 plist 內部的 restore 版本號，跟 macOS 行銷版本號不同），而當前系統是 macOS 15.3.1。這表示 staging 的資料可能是 Apple 為未來升級預先準備的，跟「有待套用的安全更新」是不同的 staging 類型。

du 跟 diskutil 數字不一致的原因

用 du 量 Preboot 會得到比 diskutil info 更大的數字（實測數據：du 報 13G，diskutil 報 8.5G）。原因是 Preboot 裡的 os.dmg 和 os.clone.dmg 是 APFS clone，du 各算一次、diskutil 共用區塊只算一次。du 和 diskutil 的差異機制見 APFS 卷結構。

判斷 Preboot 佔用時用 diskutil info 的 Volume Used Space：

1diskutil info /System/Volumes/Preboot | grep "Volume Used Space"

正常的 Preboot 結構

一台 Apple Silicon + macOS 14-16 的機器，Preboot 的典型內部結構：

1/System/Volumes/Preboot/<Volume-Group-UUID>/
2├── cryptex1/current/       # Cryptex 本體（5-7G）
3│   ├── os.dmg              # 系統安全元件
4│   ├── os.clone.dmg        # APFS clone，不額外佔空間
5│   └── app.dmg             # App 層元件（~20M）
6├── restore-staged/         # 更新暫存（0-2G，浮動）
7├── restore/                # 復原用開機資料（~800M）
8├── boot/                   # 開機載入器（~50M）
9└── var/, usr/, ...         # 開機輔助資料（~25M）

cryptex1/current/ 裡的 os.dmg 和 app.dmg 分別承擔不同層級的安全更新：OS Cryptex（os.dmg，約 5.4G）包含核心安全元件與底層系統框架；App Cryptex（app.dmg，約 20M）包含 Safari、WebKit 等使用者空間元件。兩者獨立更新——修 Safari 漏洞只需替換 app.dmg，修核心安全問題才動 os.dmg。

Volume Group UUID 正常情況只有一個，對應當前系統的 Data 卷。確認方式：

1# Preboot 裡的 UUID
2ls /System/Volumes/Preboot/ | grep -E '^[0-9A-F]{8}-'
3
4# 當前系統的 Volume Group UUID
5diskutil info /System/Volumes/Data | grep "APFS Volume Group"

什麼情況才真的有問題

基於上面的機制，判讀 Preboot 大小是否合理的依據是結構性指標，不是絕對大小。

多個 Volume Group UUID：Preboot 裡出現多個 UUID 目錄，表示曾有過多重 macOS 安裝。每組 UUID 各帶一份完整的 Cryptex 和開機資料，所以 Preboot 會翻倍。只有對應當前 Data 卷 UUID 的那個是必要的，其他是舊安裝殘留。這是 Preboot 超過 15G 最常見的原因。

restore-staged 異常堆積：超過 3G 且日期距今超過一個月，可能是下載了更新但套用失敗或被中斷。正常的處理方式是在系統設定裡完成或重新下載更新，更新完成後系統會自動清理這個目錄。

Cryptex 沒有成功替換：cryptex1/ 目錄裡除了 current 還有其他子目錄，可能是舊版 Cryptex 沒被正常替換。安裝最新的安全更新通常能解決。

這些情況都不應該用手動刪檔的方式處理。Preboot 是安全啟動鏈的一部分，APFS 的 snapshot 和 clone 關係讓手動刪除可能影響到看不見的依賴。正確路徑是透過系統更新、Recovery 模式重裝、或 Apple Support 來處理。

disk-report 的 Preboot 段落

這些判讀邏輯已整合進 disk-report 腳本的 --preboot 模式，用 diskutil info（不是 du）取實際佔用，計算 Volume Group UUID 數量，檢查 restore-staged 的大小和日期，輸出一行結論。完整磁碟診斷時（disk-report 不帶參數）會自動包含這個段落。

確認目前裝了幾組

1xcrun simctl runtime list

輸出範例：

1== Disk Images ==
2-- iOS --
3iOS 18.2 (22C150) - 6286F286-FA4F-4877-AAEF-62A162C6A2C4 (Ready)
4iOS 18.3.1 (22D8075) - 07012283-CA3D-4437-8A5F-89AE5346EEED (Ready)
5
6Total Disk Images: 2 (16.2G)

兩組各自獨立，可以分開移除。

移除流程

先清掉綁在舊 runtime 上的模擬器裝置，再刪 runtime 本體。順序顛倒的話，runtime 可能因為仍被裝置參照而拒絕刪除。

 1# 1. 關閉所有正在跑的模擬器
 2xcrun simctl shutdown all
 3killall Simulator 2>/dev/null
 4
 5# 2. 清掉不可用的模擬器裝置（綁在已刪 runtime 或舊版本上的）
 6xcrun simctl delete unavailable
 7
 8# 3. 刪除指定 runtime（用 runtime list 裡的 identifier）
 9xcrun simctl runtime delete 6286F286-FA4F-4877-AAEF-62A162C6A2C4
10
11# 4. 確認
12xcrun simctl runtime list

如果步驟 3 跑完沒報錯但 runtime 還在列表裡，通常是因為還有模擬器裝置綁在上面。回到步驟 1 和 2 重跑，或用 xcrun simctl list devices 查看哪些裝置還在用那個 runtime，手動刪掉它們：

1# 列出所有模擬器裝置
2xcrun simctl list devices
3
4# 刪除特定裝置
5xcrun simctl delete <裝置UDID>

為什麼不能手動刪檔案

一組 runtime 的資料散在多個位置（Runtime DMG、Bundle DMG、裝置資料、快取），各位置的關係和儲存機制見 runtime 架構。手動刪其中一處只會刪掉一部分，留下孤兒資料，讓 CoreSimulator 的索引跟實際檔案不一致。之後可能出現模擬器列表裡有裝置但開不了、或空間沒真正釋放的情況。simctl runtime delete 會同步清理所有相關位置。

Xcode GUI 的限制

Xcode > Settings > Platforms 也可以管理 runtime，但它把相鄰版本打包成同一個下載單位顯示。例如 iOS 18.2 和 18.3.1 在介面上可能顯示為一個 8.71GB 的「iOS 18.2 + iOS 18.3.1 Simulator」項目，無法單獨刪除其中一個。這時用 simctl 指令是更精確的選擇。

刪完之後

重跑 disk-report 確認空間釋放。如果日後需要被刪除的版本，Xcode 會在建置或開啟模擬器時提示下載，或手動從 Settings > Platforms 下載。

1# 驗證空間釋放
2df -h /System/Volumes/Data
3xcrun simctl runtime list

讀 container metadata plist

每個容器目錄根部都有一個 .com.apple.containermanagerd.metadata.plist，裡面的 MCMMetadataIdentifier 欄位就是 bundle ID。

1plutil -extract MCMMetadataIdentifier raw \
2  ~/Library/Containers/<目錄名>/.com.apple.containermanagerd.metadata.plist

這個指令需要 Full Disk Access 權限。授權路徑：系統設定 > 隱私權與安全性 > 完整磁碟取用權限，把終端機加進去，完全退出再重開。

取得 bundle ID 之後，用 App Store 搜尋或 Google 就能確認是哪個 App。

批次辨識所有 UUID 容器

 1for dir in ~/Library/Containers/*/; do
 2  name="$(basename "$dir")"
 3  echo "$name" | grep -qE '^[0-9A-F]{8}-' || continue
 4  kb="$(du -skx "$dir" 2>/dev/null | awk '{print $1}')"
 5  bid="$(plutil -extract MCMMetadataIdentifier raw \
 6    "$dir/.com.apple.containermanagerd.metadata.plist" 2>/dev/null)"
 7  ios="$(plutil -extract iOSAppOnMac raw \
 8    "$dir/.com.apple.containermanagerd.metadata.plist" 2>/dev/null)"
 9  platform=""
10  [[ "$ios" == "1" ]] && platform=" [iOS on Mac]"
11  printf '%6sM  %-40s %s%s\n' "$((kb / 1024))" "${bid:-（無法讀取）}" "$name" "$platform"
12done | sort -rn

輸出範例：

1 9961M  com.stove.epic7.ios                       D678BD0C-... [iOS on Mac]
2 8903M  tw.txwy.ios.arknights                     874686B0-... [iOS on Mac]

清除判斷

辨識出 App 之後，清除判斷依 Container 的內部結構 而定：

• Data/Library/Caches/ — 快取，清除零風險
• Data/Documents/ — 使用者資料或遊戲資源。遊戲資源是可重新下載的衍生物（帳號進度在伺服器端），確認不再玩可整個刪除。電子書庫、筆記資料庫等則需要確認有雲端備份
• iOS App on Mac 的 App 如果已從 App Store 下架，刪除容器後可能無法重新安裝

1# 確認後刪除（不可逆）
2rm -rf ~/Library/Containers/<UUID>

Steam 遊戲的辨識

Steam 遊戲的儲存機制跟 App Container 不同——資料集中在 ~/Library/Application Support/Steam/steamapps/common/，每個遊戲一個子目錄，目錄名就是遊戲名稱。

1du -shx ~/Library/Application\ Support/Steam/steamapps/common/* 2>/dev/null | sort -rh

回收空間從 Steam App 內解除安裝，手動刪 common/ 下的目錄會讓 Steam 的 manifest 跟實際檔案不一致。

Content probing 為什麼不可靠

實際發生過的誤判案例：兩個 UUID 容器被 content probing（探測目錄內容特徵）誤判為 HoYoverse 遊戲。實際讀 plist 後發現是 Epic Seven（第七史詩）和 Arknights（明日方舟），完全不同的廠商。

Content probing 的根本問題是同樣的目錄名（data.pack）在不同遊戲裡代表不同東西，遊戲引擎共用（Unity、Unreal）會產生相似的目錄結構。一個 heuristic 命中只代表結構相似，輸出一個看起來確定的名字會導致使用者基於錯誤資訊做決策。

讀 plist 的 bundle ID 是唯一可靠的辨識方法。Content probing 只能作為 plist 讀不到時的 fallback，且必須標示「無法確認，僅供參考」。

一個 App 的真實佔用不等於它的 .app 大小

判斷一個 App 吃多少空間，要算的是它的總足跡（footprint），而不是 /Applications 裡那顆 .app 的大小。.app 只是程式本體，App 跑起來產生的資料（下載內容、快取、登入狀態、設定、日誌）絕大多數寫在 ~/Library 底下的好幾個不同位置，跟 .app 完全分家。

這台機器上最極端的例子是 Steam：它的 .app 只有 10.8M，但遊戲資料佔了 8.1G，兩者差了近 800 倍。只看 /Applications 的大小排序，Steam 會排在很後面，完全看不出它是全機第一大戶。同樣地，Amazon Kindle 的 .app 才 138M，書庫卻在沙箱容器裡佔了 3.2G。這就是為什麼「按目錄統計」和「按 App 統計」會給出完全不同的排行；要回答「哪個 App 該清」，必須把佔用聚合回 App。

佔用散落在 ~/Library 的哪些地方

聚合的第一步是知道一個 App 會把資料寫到哪些固定位置。下表只列與空間相關的主要位置（非 ~/Library 全量），macOS 對它們有約定，每個位置承擔不同責任，也決定了它能不能安全清掉。

這張表的關鍵分界是「快取」與「資料」。Caches 和 HTTPStorages 是純衍生物，清掉只是讓 App 下次重新下載或重建，最多重新登入一次，所以是回收空間時的首選。Application Support、Containers、Group Containers 則是使用者資料，Steam 的遊戲、Kindle 的書庫、聊天記錄都在這裡，刪了就真的沒了。Group Containers 還要多一層留意：它是同一個開發商旗下多個 App 共享的目錄，動它可能同時影響好幾個 App。

腳本對每個 App 把上面這些位置全部找出來、用 du 量實際佔用、加總成一個數字，再附上逐項明細，讓人一眼看出「這 4G 裡有多少是可清的快取、多少是動不得的資料」。

命名不一致是聚合的主要難點

把資料夾正確歸給某個 App 的難點在於：macOS 對這些目錄沒有統一的命名規則。有些 App 用它的 bundle id（例如 com.valvesoftware.steam）當目錄名，有些直接用 App 的顯示名稱（例如 Steam），同一個 App 的不同位置甚至各用一種。iOS App on Mac 的容器更用 UUID 命名，完全看不出是哪個 App（辨識方法）。

腳本的做法是對每個 App 先讀出它的 bundle id，然後 Caches、Application Support、Logs 這幾個位置兩種命名都比對一次，bundle id 專屬的位置（Containers、HTTPStorages、Saved Application State）則用 bundle id 找。Group Containers 又是另一種格式，名稱前面多一段開發商的 team id（10 碼英數，像 ABCDE12345.group.com.foo），因此改用 bundle id 做子字串比對。這套規則涵蓋了絕大多數 App，但用罕見自訂命名的資料仍可能漏抓，這是聚合式估算的固有邊界，腳本在輸出裡據實標明「可能漏抓」而不假裝是精確值。

Homebrew 要分開算

透過 Homebrew 裝的工具不在 /Applications，需要獨立統計。佔用分兩類（概念詳見 Homebrew 知識卡）：命令列工具與函式庫（formula）在 Cellar/，GUI App 的下載 artifact 與 metadata（cask）在 Caskroom/。cask 安裝的 .app 本體實際放在 /Applications，已被前面的 App 聚合排行計入；Caskroom/ 存的是安裝來源與版本資訊，體積通常遠小於 App 本體，兩邊不重複計。

這台機器的 formula 前幾名是開發語言執行環境：dotnet@9 634M、兩個版本的 openjdk 合計 600M、mysql 292M、go 258M。formula 會多版本並存（例如 python@3.13 和 python@3.14 各算各的），所以腳本把整個 formula 目錄一起計。除了已安裝的部分，腳本還列出 brew --cache 的下載快取，以及 brew cleanup -n 預估可回收的舊版本（-n 是 dry-run，只報告不刪），跟整支腳本的唯讀原則一致。

聚合一律用 du 取實際佔用

App 各位置的聚合一律用 du -skx 取實際佔用，而不是 ls / find -size 的邏輯大小。sparse 檔（稀疏檔）只有寫入過的區塊才真正佔磁碟，宣告的邏輯大小可能是實際佔用的數十倍；容器與資料目錄裡正好常有 VM 映像、容器磁碟這類 sparse 檔，拿邏輯大小加總會把整份聚合排行灌水。完整的 sparse 踩坑案例見 disk-report 那篇。

-x 讓 du 不跨越檔案系統邊界，避免把掛載進來的卷重複計入；-k 統一用 KB 當單位，方便把各位置的數字加總後再換算成人類可讀的 G / M。

實測結果

下面是這台機器的實測排行（名次因個人使用習慣而異）；要看的是聚合排行和「按目錄統計」給的印象差多少：

全機掃到 65 個 App、聚合總計 48.2G。這份排行的價值在於它直接指向「該從哪裡下手」，而判讀邏輯可以套到任何人的排行上：本體小、資料大的 App（這台是 Steam、Kindle）要回收就得處理書庫與遊戲本身；純快取大的（這台是 Dia 的 1.6G）清掉零風險；本體就大的開發工具（Xcode、Android Studio）除非不再開發否則動不得。同一個總數字底下，可清的比例天差地別，這正是逐項明細要回答的問題。

聚合的邊界：總計不等於整機

這個 48.2G 是「能歸屬到已安裝 App 的部分」之和，不是 ~/Library 的全量。disk-report 那篇量到的 ~/Library 約 70G，差額落在幾類刻意不歸進單一 App 的位置。

最大的一塊是 ~/Library/Developer（這台約 5.5G，幾乎全是 Xcode 的 DerivedData、CoreSimulator 與 iOS DeviceSupport）。它們是 Xcode 與模擬器產生的共用產物，硬塞給 Xcode 會誇大這顆 App、塞給別人又不對，app-report 比照 Homebrew 把它單獨列成一段（app-report --dev）。也因為這樣，上面排行裡的 Xcode 只算到 .app 本體，它的建置產物要看 Developer 那段——這也是為什麼 disk-report 會把「Xcode DeviceSupport」列為大戶，而逐 App 排行卻看不到：那筆資料正住在這個不歸單一 App 的位置。

其餘排除的還有 iCloud 與雲端硬碟的本地鏡像（Mobile Documents、CloudStorage）、已移除 App 留下的孤兒資料夾、以及 Preferences。排行掃的是 /Applications、~/Applications、/Applications/Utilities 與 Setapp、Mac App Store 裝的 App；直接從 DMG 跑、沒搬進 Applications 的 App 不會出現在排行，但它的 ~/Library 資料若命名對得上仍可能部分計入。

還有一個方向相反的誤差要記得：這是估算不是精算。同一份資料若以 APFS clone 出現在多個被聚合的位置，逐位置分開跑 du 會各自計入（du 只在單次執行內對硬連結以 inode 去重，對 APFS clone 不去重），聚合值可能偏高。要看整個 ~/Library 到底多大、由誰佔，回到 disk-report 的逐層 du。

固化成 app-report 腳本

把這套聚合邏輯寫成腳本，往後想知道「誰在吃空間」就一行重跑，不必每次重想要比對哪些目錄、要怎麼處理命名差異。腳本和 disk-report 收在同一個公開 repo tarrragon/scripts 裡，維持「跟專案無關的系統工具放個人 bin」的一致做法。

兩支腳本在同一個 repo；若已為 disk-report clone 過 ~/Projects/scripts，跳過 clone、只做 symlink。首次安裝則把 repo clone 下來，再把腳本本體 symlink 到個人的 ~/.local/bin，這樣本機呼叫的永遠是 repo 的最新版：

1git clone https://github.com/tarrragon/scripts.git ~/Projects/scripts
2ln -s ~/Projects/scripts/app-report/app-report ~/.local/bin/app-report

PATH 設定同 disk-report（見 macOS 新機基礎建設）。裝好後直接呼叫：

1app-report           # 完整報告：App 聚合排行 + Developer + Homebrew
2app-report --apps    # 只看 App 聚合排行（預設前 30）
3app-report --apps 50 # 排行顯示前 50
4app-report --dev     # 只看 ~/Library/Developer 開發工具共用資料
5app-report --brew    # 只看 Homebrew

要清哪個 App，看完明細再動手：移掉 .app 並清對應的 ~/Library 資料夾（報告每個 App 下方列的路徑就是清除對象；先從 Caches / HTTPStorages 開始，確認再考慮資料目錄），Homebrew 用 brew cleanup -s。

兩支腳本的分工

disk-report 與 app-report 是磁碟清理的兩個接力棒。前者在卷與目錄層找出最大的子樹，通常落在 ~/Library；後者接手把那棵子樹拆到 App，看出具體是誰佔的、各自有多少是可清的快取。先 disk 找方向、再 app 定位到人，兩支都唯讀，回收的最後一步都留在人這一端。

先裝 Homebrew，它是後面一切的基礎

macOS 本身沒有內建的第三方套件管理工具，而後面幾乎每一項補強（命令列工具、開發語言、甚至部分 GUI App）都靠它安裝。沒有 Homebrew，這份清單的其他項目全部無從裝起，所以它排第一。

安裝過程會要求輸入登入密碼（sudo），並自動下載 Xcode Command Line Tools，畫面可能停住數分鐘屬正常。

1/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

裝完還要把 Homebrew 的執行檔目錄加進 PATH，shell 才找得到 brew 與之後用它裝的工具。Homebrew 的安裝前綴依晶片而異：Apple Silicon 機器裝在 /opt/homebrew、Intel 機器裝在 /usr/local。安裝腳本結尾會印出對應這台機器的設定指令，照它印的路徑寫進 ~/.zprofile 讓每次開 shell 都生效。以下以 Apple Silicon 為例，Intel 機器把前綴換成 /usr/local 即可：

1echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
2eval "$(/opt/homebrew/bin/brew shellenv)"

這一步做完，驗證安裝成功：

1brew --version   # 應印出 Homebrew 4.x.x

版本號印出來，Homebrew 就能當後面所有項目的安裝來源。

把 bash 更新到 5.x

bash 是裝完 Homebrew 後最值得優先換掉的內建工具。macOS 的 /bin/bash 長年凍結在 3.2 系列（2006 年釋出，目前是 patchlevel 57），Apple 不再更新它，原因是 bash 4 改用 GPLv3 授權、Apple 不願隨系統散布。對寫腳本的人來說，這代表 associative array、${var,,} 大小寫轉換、mapfile 等近二十年的語法都用不了。這個授權轉折的完整脈絡（反 Tivoization 條款），以及 BSD userland 帶來的另外兩種撞牆形態——GNU 工具缺席、同名工具行為不同——見 macOS 的 BSD userland。

正確做法是用 Homebrew 另外裝一份新版並排存在，而不是覆寫系統版。/bin/bash 在唯讀的系統卷上、受 SIP（System Integrity Protection）保護，覆寫會被擋下：

1brew install bash

這會把 bash 5.x 裝到 /opt/homebrew/bin/bash，完全不碰 /bin/bash。因為前一步已經把 /opt/homebrew/bin 排在 PATH 前面，用 #!/usr/bin/env bash 起手的腳本就會自動改用新版。裝完驗證一下版本確實切過去：

1env bash --version   # 應顯示 5.x
2/bin/bash --version  # 系統版仍是 3.2.57，沒被動

要留意的是互動 shell 在現代 macOS 預設是 zsh，這一步不影響它。更新 bash 的目的是給 #!/usr/bin/env bash 腳本一個現代執行環境，不是換登入 shell。真要把新版 bash 當登入 shell，才需要額外把它加進 /etc/shells 再 chsh。

把 ~/.local/bin 加進 PATH，放個人腳本

跟專案無關的小工具（例如 disk-report 與 app-report 這類系統診斷腳本）需要一個能在任何地方直接呼叫、又不污染專案 repo 的家。慣例是個人的 ~/.local/bin，把它建好並掛上 PATH。

1mkdir -p ~/.local/bin
2echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zprofile
3export PATH="$HOME/.local/bin:$PATH"

目錄建好、PATH 掛上後，確認它確實生效：

1echo "$PATH" | tr ':' '\n' | grep "$HOME/.local/bin"

之後把腳本 symlink 進這個目錄就能直接當指令用。

後續項目

基礎建設到位後，第一個掛上去的實用腳本就是系統診斷：磁碟空間診斷的 disk-report 與 按 App 聚合佔用的 app-report，兩支都 symlink 進 ~/.local/bin 直接當指令用。

這份清單會隨著之後遇到的需求往下增補，新項目接在這裡。原則維持不變：基礎建設排前面，依賴它的補強排後面，每一項都寫清楚「為什麼要做」而不只是貼指令。

最後把整套診斷固化成一個唯讀的 disk-report 腳本，往後同類情況可以一行指令重跑。

先確認問題是「真的滿」還是「浮動的假象」

排查磁碟的第一步是分辨空間到底去哪：是被真實檔案佔走，還是被系統的快照與 purgeable（系統可隨時回收的緩衝空間）暫時佔住。這兩者的處理方式完全不同，先分清楚才不會白清。

在 APFS（Apple File System，macOS 的預設檔案系統）上，根目錄 / 是唯讀的系統封印卷，真正存放使用者資料的是 /System/Volumes/Data，而它們和其他卷（Preboot、Recovery、VM、模擬器 runtime）共用同一個 container（容器，APFS 管理空間的最上層單位）的空間池。判斷「還剩多少」要看整個 container 的可用空間，而不是單一卷的數字。

1df -h /System/Volumes/Data
2diskutil info /System/Volumes/Data | grep -iE "Container Free Space|Container Total Space"

這次的結果是資料卷 100% 滿、整個 container 只剩約 591MB。確認確實滿載、不是顯示誤差，後面才值得花力氣找佔用大戶。

「空間掉了又回來」的根因：本地快照與 purgeable

空間在幾小時內反覆消長、清 cache 卻無效，最常見的原因是 Time Machine 的本地快照（local snapshots）加上 macOS 的 purgeable 空間，而不是某個看得見的檔案。這是排查時要先排除的一條線。

本地快照的運作方式是：Time Machine 啟用時，系統約每小時自動建立一張快照「凍結」當下狀態，好讓本地也能做時光機回溯。這些被凍結的資料，正是先前以為已刪除、卻怎麼清都不會釋放的空間。快照保留約 24 小時（Apple 的 thinning 策略，觀察值），或在磁碟空間壓力過大時提前清除；後者正是「過一陣子空間又回來」的來源。若從未設定 Time Machine，這條線可跳過——沒啟用就不會有 local snapshot。

1tmutil listlocalsnapshots /System/Volumes/Data

這次查的時候快照數是 0，但這不代表它不是元兇——恰恰相反，是磁碟已經滿到讓系統把快照全數清光了。判讀訊號是：若這個指令平常列出多筆快照、且磁碟空間在數字上頻繁浮動，浮動量就來自這裡，跟手動清的 cache 無關。根治方向是把總用量降下來、讓磁碟保有餘裕，系統就不會一直貼著上限狂建狂清快照。

purgeable 是同一條線的另一半，但它沒有好用的精確讀數。diskutil apfs list 能看 container 層的概況，而 purgeable 主要由快照與系統快取構成、本來就會自己浮動。處理方式跟快照一樣：把總用量降下來、讓系統在空間有壓力時自行釋放，而不是找指令直接清它。「沒有直接讀數」本身就是判讀邊界——看到可用空間和「實際檔案總和」對不上時，差額多半就在這塊浮動緩衝，不必懷疑是哪個檔案在搞鬼。

用實際佔用值找大戶，避開 sparse 假大小

找佔用大戶要用 du（實際佔用的磁碟區塊）排序，不能依賴 ls -l 顯示、或 find -size 篩選所用的邏輯大小。對一般檔案兩者相同，但對 sparse 檔（稀疏檔）差距可以是好幾十倍，誤判會追錯目標。

這次就踩到這個陷阱。find 列出近期修改的大檔時，OrbStack（一套容器與 VM 執行環境）的虛擬磁碟映像顯示為 228G，看起來像頭號兇手；但用 du 一量，實際佔用只有 1.9G。同樣地，macOS Podcasts 在 tmp 塞的一堆 .tmp.resize.img 顯示有數十個檔，實際只佔 3.5M。這些都是 sparse 檔：宣告了很大的邏輯大小，但只有寫入過的區塊才真正佔磁碟。

1# 實際佔用（正確）
2du -sh ~/some/large.img
3
4# 顯示大小（對 sparse 檔會嚴重高估，誤判用）
5ls -lh ~/some/large.img

定位順序是由外往內逐層收斂：先看家目錄前 20 大，鎖定最大的子樹（這次是 ~/Library 70G 左右），再往下展開 ~/Library/Application Support、~/Library/Containers，直到找到具體的檔案或目錄。Containers 裡的 UUID 目錄是 iOS App on Mac 的容器，辨識方式見 Container 辨識。

1du -shx ~/* ~/.[!.]* 2>/dev/null | sort -rh | head -20
2du -shx ~/Library/* 2>/dev/null | sort -rh | head -12

-x 讓 du 不跨越檔案系統邊界，避免把掛載進來的唯讀卷（例如 iOS 模擬器 runtime）重複計入；~/.[!.]* 這個寫法只展開以單一點開頭的隱藏檔，排除掉 . 和 .. 兩個會被一般 .* 誤抓進來、算出整個家目錄大小的假項目。

這次找到的佔用大戶與處理

定位出來的大戶集中在開發工具鏈與閒置的本地資料，多數可逆、刪了之後需要時會自動重建或可重新下載。下面的項目與數字都是這台機器的實測，換一台機器組成會完全不同；值得帶走的是每一項背後的判讀問題，不是這份清單本身。具體刪除指令因工具而異（Android Studio GUI、rm -rf、ollama rm），本文只做診斷與定位，刪除操作留給各工具自身的文件。以下逐項說明判讀依據。

Android NDK 的判讀要回到「誰在用它」：這次專案是 Flutter，NDK 版本由 flutter.ndkVersion 決定，而不是專案自己 pin。查當前 Flutter 要求的版本後發現，本機裝的兩版都是舊 Flutter 留下的殘留，於是保留較新的一版、刪掉最舊的。判斷可不可刪的關鍵是先確認「現在到底用哪版」，而不是看修改日期就動手。

Claude 桌面的 vm_bundles 是最大單一項目（11G）。它是桌面 App 的 Cowork 功能在本地沙箱 VM 裡執行程式用的根檔案系統映像。關鍵判讀是：它不是每次開 App 就重建——映像的修改日期停在數月前，是一次性佈建、之後沿用。只有實際使用 Cowork 沙箱時才會佈建和更新。所以對只用終端機 CLI、桌面 App 僅拿來聊天的人，這 11G 是純佔用，可以安全刪除；唯一後果是哪天實際開了 Cowork session，它會重新佈建。

剩下三項的判讀各有自己的關鍵問題。閒置的 AVD 與 system-image 是「一個 API 版本一組」的綁定，停用某個 Android 版本時要連 AVD 帶它依賴的系統映像一起刪，只刪一邊會留下半套。ollama 本地模型的判斷是「改用雲端後還會不會在本地跑」，閒置的大模型可刪，但小的 embedding 模型常被其他工具當依賴、刪了會牽連（ollama 模型的累積速度與專屬清理 idiom，見 本地 LLM 的資源管理）。Xcode 的 iOS DeviceSupport 則是實體裝置接線除錯時產生的符號快取，可以放心刪——下次接上同一台裝置除錯時 Xcode 會自動重建。

這幾項合計回收約 17G，可用空間從約 591MB 拉回到 18G，磁碟脫離滿載。

把診斷固化成 disk-report 腳本

一次性查完之後，把這套順序寫成腳本的價值是：下次同類情況不必重新回想指令與判讀順序，一行就能重跑，而且固定先看快照、再用實際佔用值，不會又掉進 sparse 假大小的陷阱。

腳本收在公開 repo tarrragon/scripts，而不是放進某個專案的 bin/。它跟任何專案無關，連到個人 bin 才能在任何地方直接呼叫，也不會污染專案 repo。安裝方式是 clone 下來、把腳本本體 symlink 到 ~/.local/bin：

1git clone https://github.com/tarrragon/scripts.git ~/Projects/scripts
2ln -s ~/Projects/scripts/disk-report/disk-report ~/.local/bin/disk-report

這一步預設 ~/.local/bin 已在 PATH 上。若還沒設定，做法見 macOS 新機基礎建設 的對應項目。腳本刻意設計成唯讀：只報告、不刪除，刪什麼由人看完報告再決定。

1disk-report              # 完整診斷：總覽 + 快照狀態 + 各層大戶 + 開發環境可清項
2disk-report --growing    # 只看過去 180 分鐘內長大的大檔（抓動態暴增最快）
3disk-report --growing 60 # 改成過去 60 分鐘

--growing 模式對應的是本文開頭那個「幾小時內暴增」的情境：當空間正在快速消失、想抓現行犯時，直接列出近期被寫入的大檔，比逐層 du 更快定位。

1find "$HOME" -type f -size +50M -mmin -180 2>/dev/null \
2  -exec du -h {} \; 2>/dev/null | sort -rh | head -25

50M 的下限是為了過濾日常小檔雜訊、鎖定單一大檔暴增；若懷疑是大量小檔累積吃空間（如快取碎片），這個門檻抓不到，要回逐層 du 看目錄總量。排序依據同樣是 du 的實際佔用值，而不是 find -size 的邏輯大小門檻，理由和前面一致：避免 sparse 檔的邏輯大小把排序帶歪。

排查順序總結

這次的方法可以收斂成一條固定順序，往後遇到任何「磁碟莫名變滿」都先照這條走：

1. 先看 container 可用空間，確認是真滿還是顯示誤差。
2. 再查本地快照與 purgeable，排除「掉了又回來」的浮動來源。
3. 用 du -shx 由外往內逐層找大戶，全程以實際佔用值判斷，不信 ls / find 的顯示大小。
4. 對每個大戶問「現在誰在用它」再決定刪不刪，可逆的優先清。
5. 把整套順序固化成唯讀腳本，下次一行重跑。

第 3 步若收斂到 ~/Library 這種多個 App 共用的大目錄，按目錄統計只能看出 Caches、Containers 各多大，看不出是哪幾個 App 佔的。把這棵子樹再按 App 拆開的做法，見 macOS App 聚合佔用報告。

Macos 不同螢幕的多桌面跑到錯誤的螢幕。

Why ?

因為我會用並行裝置連接平板當成額外的螢幕，但是如果中斷再連接有時候會造成MACOS辨識多桌面出錯，導致無法正常切換桌面。

How to solve this ?

方法一：重置 Mission Control 偏好設定

這會清除所有顯示器的 Spaces 配置（等於重置多桌面設定）。

打開 終端機（Terminal）

輸入以下指令並按 Enter：

1defaults delete com.apple.spaces #清除設定
2killall Dock                     #重啟 Dock

Dock 重啟後，Mission Control 的桌面配置會被重置，所有螢幕會只剩下「一個桌面」。 注意：這會刪除所有已建立的桌面（Spaces），但不會影響 App 或檔案。

方法二：暫時停用「顯示器有單獨的空間」

macOS 會為每個螢幕建立自己的桌面空間，這個設定有時會造成錯亂。

前往 系統設定 > 桌面與 Dock

找到 「顯示器有單獨的空間」（英文為 Displays have separate Spaces）

取消勾選

登出並重新登入你的帳號

重新勾選回來（如果你平常需要它）