概念位置

Homebrew 在 macOS 跟使用者要安裝的工具之間、扮演「公開 registry + 本地套件管理」的角色。它維護一份名為「formula」的 Ruby 腳本清單、每個 formula 描述某個工具怎麼下載、編譯、安裝。執行 brew install ollama 時、Homebrew 找到 ollama formula、下載對應 bottle（預編譯二進位）、放到 /opt/homebrew/（Apple Silicon）或 /usr/local/（Intel Mac）、再把可執行檔 symlink 到 /opt/homebrew/bin/。新機從零的完整安裝順序（含第一次裝 Homebrew、PATH 設定與晶片前綴差異）見 macOS 新機基礎建設。

brew services 是 Homebrew 附帶的服務管理子命令、把指令封裝成 macOS 原生的 launchd service、處理「開機自動啟動 / 停止 / 重啟」需求。

可觀察訊號與例子

日常會碰到的 brew 指令：

Apple Silicon Mac 上的關鍵路徑是 /opt/homebrew/、子資料夾各有角色：bin/（可執行檔）、var/log/（服務 log）、Cellar/（套件實際內容）、opt/（版本無關的 symlink）。看到「/opt/homebrew/var/log/ollama.log」時、就是 brew 管理的 Ollama 服務 log 位置。

設計責任

用 brew 安裝 vs 用官方 .dmg / .pkg 的取捨：CLI 工具（ollama、llama.cpp、git 等）走 brew、好處是統一升級路徑；GUI 應用（LM Studio、Docker Desktop 等）多半改下載官方安裝包、因為 brew cask 不一定即時跟上版本。第一次裝 Homebrew 自己用官方 install script（在 brew.sh）、之後其他工具都從 brew 走。

概念位置

launchd service 用一份 plist（property list、XML 格式設定檔）描述「要跑哪個程式、何時啟動、出問題時要不要重啟、log 寫到哪裡」。plist 放在三個位置之一、決定服務的觸發範圍：

Homebrew 的 brew services 子命令是 launchd 的 wrapper、產生 plist 並放進 ~/Library/LaunchAgents/、避免使用者直接手寫 XML。Apple Silicon Mac 上產生的檔名形式是 homebrew.mxcl.<service>.plist。

可觀察訊號與例子

執行 brew services start ollama 後可以驗證實際發生的事：

1# 看 plist 內容
2cat ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist
3
4# 用 launchctl 看服務狀態
5launchctl list | grep ollama
6
7# 看服務 log（Apple Silicon）
8tail -f /opt/homebrew/var/log/ollama.log

plist 內常見的鍵：ProgramArguments（要跑哪個指令）、RunAtLoad（開機就啟動）、KeepAlive（crash 後自動拉回）、StandardOutPath / StandardErrorPath（log 路徑）。出問題時先看 log 路徑指向的檔案、能直接看到 service 的 stdout / stderr。

服務管理常用指令：

1brew services list             # 列出所有由 brew 管理的服務
2brew services start ollama     # 啟動 + 註冊自動啟動
3brew services stop ollama      # 停掉服務、保留 plist
4brew services restart ollama   # 升級套件後重啟

直接用系統的 launchctl 也行、但語意較底層、實務上有 brew 包裝就用 brew。

設計責任

選擇「launchd service」vs「前景手動跑 ollama serve」的判讀：日常用機建議用 launchd service、好處是重開機自動拉起、出問題的 log 有固定位置可看；只在偶爾用本地 LLM 的場景、保持手動跑反而省記憶體（沒在用就停掉）。升級套件後記得 brew services restart、否則跑的還是舊版二進位。

概念位置

Shell（zsh / bash）執行一個程式時、預設讓程式佔住 terminal、stdin / stdout / stderr 直接連到使用者眼前的視窗、稱為前景 process。指令尾巴加 & 改成背景 process、shell 立刻拿回 prompt 控制權、程式繼續跑但不佔住 terminal。背景 process 仍綁在當前 shell session、關掉 terminal 視窗時通常會被 SIGHUP 終止；要完全脫離 shell 生命週期、得改用 launchd service 或 nohup / disown 等機制。

可觀察訊號與例子

shell 控制 process 的關鍵操作：

排錯常用的兩個工具（兩者跟 shell job 不直接相關、是 macOS 系統工具）：

對 macOS 新手最常遇到的兩個事故：一個是「前景跑 server 後不知道怎麼脫身」、解法是 Ctrl+Z 暫停 + bg 改背景、或下次改用 & 啟動；另一個是「pkill 沒指定夠精確的 pattern、誤殺其他 process」、解法是先用 ps aux 加 grep 確認 PID 再 kill。

設計責任

選前景 vs 背景的判讀：debug 場景前景跑、能直接看到 log；日常使用改 launchd service 跑、跟 shell session 完全脫鉤。& 適合「terminal 開著就讓它跑、關掉也沒關係」的臨時場景、不適合需要長期穩定的服務。排錯時養成「先 lsof 找誰佔資源、再 ps 確認身分、最後才 kill」的順序、避免誤殺。

macOS 原生 Window Tiling（macOS 15+）

macOS Sequoia（15，2024 年 9 月）內建了 window tiling 功能：鍵盤快捷鍵把視窗貼到螢幕的半邊或四分之一、拖拉到邊緣自動貼齊（edge snap）、相鄰視窗可以組成 tile group 一起調整比例。

原生 tiling 的邊界：沒有多工作區管理、快捷鍵自訂空間有限（只能用系統偏好設定裡的固定選項）、不支援自動平鋪（仍然是手動觸發的 snap，不會在開新視窗時自動重排）。

如果「貼到半邊 + 邊緣吸附」就足夠，原生功能免安裝即可使用。以下第三方工具解決的是原生功能做不到的事：更多排列選項（Rectangle）、自動平鋪（Amethyst）、完整的鍵盤工作流加多工作區（AeroSpace / yabai）。

Rectangle

免費、開源。用快捷鍵把視窗貼到螢幕的半邊、三分之一、角落。不是自動平鋪——每個視窗都要你主動下指令。安裝後開箱即用，學習成本最低。

適合的情境：只需要快速排版、不想花時間學新操作邏輯、偶爾分割就滿足需求。

配置檔位置：~/Library/Preferences/com.knollsoft.Rectangle.plist（macOS plist 格式，不太適合手動編輯，通常用 GUI 設定）。

Amethyst

自動平鋪，安裝後視窗就會自動排列。提供多種 layout（tall, wide, fullscreen, column 等）可以用快捷鍵切換。設定比 Rectangle 多但比 yabai 少，是「想要自動平鋪但不想深度折騰」的選擇。

配置檔：~/.amethyst.yml，YAML 格式，可以版控。

AeroSpace

近年最受歡迎的選擇。核心優勢是不需要關閉 SIP（System Integrity Protection）——它用自己實作的虛擬工作區概念，不依賴 macOS 原生的 Spaces，因此繞過了很多系統層的限制。

配置是純文字的 TOML 檔 ~/.aerospace.toml，改完即時生效。工作區模型靈活，多螢幕支援被普遍認為比 yabai 穩定。

 1# ~/.aerospace.toml 片段
 2after-startup-command = ['workspace 1']
 3
 4[gaps]
 5inner.horizontal = 10
 6inner.vertical = 10
 7outer.left = 10
 8outer.right = 10
 9
10[mode.main.binding]
11alt-h = 'focus left'
12alt-j = 'focus down'
13alt-k = 'focus up'
14alt-l = 'focus right'
15alt-shift-h = 'move left'
16alt-shift-j = 'move down'
17alt-shift-k = 'move up'
18alt-shift-l = 'move right'
19alt-1 = 'workspace 1'
20alt-2 = 'workspace 2'
21alt-3 = 'workspace 3'

配置結構直覺：gaps 控制視窗間距、binding 定義快捷鍵對應的動作。整份檔案進 dotfile repo 就能跨機器還原操作習慣。

yabai + skhd

功能最完整的 macOS tiling WM。yabai 負責視窗管理，skhd 負責快捷鍵綁定。支援 BSP（binary space partitioning）樹狀分割——每次開新視窗都是把現有空間二分，形成一棵樹，你可以操作樹的節點來旋轉、交換、調整比例。

代價是部分進階功能（某些視窗操作、取消動畫）需要部分關閉 SIP。對某些人這是門檻，對另一些人不是問題。

配置檔是 shell script：.yabairc（yabai 設定）和 .skhdrc（快捷鍵設定），進 dotfile repo 管理。

 1# .yabairc 片段
 2yabai -m config layout bsp
 3yabai -m config window_gap 10
 4yabai -m config top_padding 10
 5yabai -m config bottom_padding 10
 6
 7# 某些 app 不適合平鋪，設為浮動
 8yabai -m rule --add app="System Preferences" manage=off
 9yabai -m rule --add app="Calculator" manage=off
10yabai -m rule --add app="Finder" title="Info" manage=off

選型判讀

選工具的判準不是「哪個最強」，而是「你願意花多少時間、想要多少控制權」。

只需要快速排視窗、不想改工作習慣，Rectangle 足夠。想要自動平鋪但學習曲線要短，Amethyst 是進入點。想要完整的平鋪工作流、多工作區管理、純文字配置、又不想動系統安全設定，AeroSpace 是目前多數人推薦的首選。想要最大的控制權、願意處理 SIP 和更複雜的配置，yabai 給你最多彈性。

從 Rectangle 跳到 AeroSpace 或 yabai 是一次操作思維的轉換——從「我指定每個視窗去哪」變成「我操作版面結構、WM 負責排列」。這個轉換需要一兩週的適應期，適應期內效率會暫時下降。

Kando 是一個跨平台的**圓盤選單（pie menu / marking menu）**工具：綁一個快捷鍵後，選單會在游標位置彈出，用滑鼠往某個方向滑動或點擊就能選到項目。每個項目可以執行指令、模擬快捷鍵、開啟網址/檔案、貼上文字或串成巨集。

• 專案：https://github.com/kando-menu/kando
• 使用說明：https://kando.menu/usage/

它最關鍵的特性是標記模式（marking mode）：選單結構固定後，可以靠肌肉記憶往某個方向「甩」一下盲選，不需要看著選單找項目。這跟「打字找東西」的啟動器（Raycast / Alfred / Spotlight）是不同的互動範式。

適用判準（先判斷再設計）

Kando 補的是一個特定空缺：手已經在滑鼠/觸控板上、不想切回鍵盤、而且動作有空間對應。它跟鍵盤快捷鍵或啟動器是並存關係，不是替代。判斷一個動作該不該交給 Kando，用以下三條：

1. 動作數量超過快捷鍵好記的上限。同類動作一旦超過七八個，組合鍵就開始互相打架、記不住；圓盤選單用空間位置取代記憶。
2. 當下手在滑鼠、切回鍵盤是中斷。瀏覽、看文件、看設計稿時，打字啟動器反而要先把手移開；圓盤選單原地彈出。
3. 動作有方向語意，盲操作就能命中。例如「左半邊視窗」往左滑、「下一個螢幕」往外圈滑。有方向對應的動作練熟後可以完全不看選單。

三條不必同時滿足，但命中越多越適合。反過來說，低頻、無方向語意、又需要打字輸入參數的動作，留在啟動器或 CLI 比較好。

macOS 工程師的應用場景

以下幾組依「契合 Kando 的程度」排序，越前面方向語意越強、回報越快。

1. 視窗排版（最契合）

方向天然對應位置，這是 Kando 比 Rectangle 純快捷鍵更直覺的地方：

• 往左滑放左半螢幕、往右放右半、往上全螢幕、往下置中浮動
• 對角線放四分之一角落
• 外圈再包一層：丟到下一個螢幕、移到上一個 Space

底層用 simulate hotkey 去觸發 Rectangle 或 yabai。練熟後完全盲操作，不用記「左半邊是哪組三鍵組合」這種反直覺對應。

2. 瀏覽器內「當前頁面接我的工作流」

看 PR、issue、文件時手在滑鼠上，這時甩一下選單把當前頁面導進後續流程：

• 複製當前 URL 成 Markdown 連結
• 把選取文字丟進 AI（觸發 Raycast AI / ChatGPT 的 hotkey，或貼到剪貼簿）
• 存進筆記軟體
• 在編輯器開對應的 local repo

3. 開發環境一鍵啟動（巢狀選單）

用 run command，適合放每天重複開的那幾個專案：

• 外圈按專案分
• 內圈每個專案：用 IDE 開、開 terminal 到該目錄、開 PR 頁、開 CI dashboard、docker compose up

4. 常用 snippet / 樣板貼上

用 paste text，放那些「記不得但常用」的東西：

• Email 簽名、PR 描述模板、commit message 前綴
• 常用 emoji / 符號
• 長的 shell one-liner

5. 系統狀態切換

toggle 類，平常要進設定點半天的：

• 勿擾模式、深色/淺色主題、防睡眠、切換音訊輸出裝置、螢幕錄製/截圖

6. Git / 容器 context 切換

git 日常走 CLI，但切 context 這種低頻又記不住名字的適合放選單：

• kubectl context / namespace 切換
• AWS profile 切換
• docker 清理、重啟某個 compose service

建構自己模式的起步建議

別一次設計大選單。先只做視窗排版那組，因為方向對應最直覺、回報最快、最容易養成「想到就甩一下」的習慣。等這個習慣固定了，再依「這禮拜我重複做了什麼、又懶得記快捷鍵」逐步往其他組長。一開始就塞滿，反而會因為記不住結構而棄用。

設定範例：視窗排版（Magnet 版）

底層用 hotkey 型項目去打 Magnet 的預設快捷鍵（Magnet 的修飾鍵是 Control+Option，Option 在按鍵碼裡是 AltLeft）。八個項目用 angle 釘死在八個方向，方向語意對齊位置：左滑放左半、右滑放右半、上滑最大化、下滑置中、四個對角放四分之一角落。練熟後可以盲操作。

Kando 的角度規則是 0 在正上方、順時針遞增（90 右、180 下、270 左）。每個 hotkey 都設 delayed: true，讓按鍵在選單關閉後才送出，這樣 Magnet 作用的是「開選單前那個聚焦視窗」而不是 Kando 的 overlay。

  1{
  2  "menus": [
  3    {
  4      "root": {
  5        "type": "submenu",
  6        "name": "視窗排版",
  7        "icon": "grid_view",
  8        "iconTheme": "material-symbols-rounded",
  9        "children": [
 10          {
 11            "type": "hotkey",
 12            "data": { "hotkey": "ControlLeft+AltLeft+Enter", "delayed": true },
 13            "name": "最大化",
 14            "icon": "fullscreen",
 15            "iconTheme": "material-symbols-rounded",
 16            "angle": 0
 17          },
 18          {
 19            "type": "hotkey",
 20            "data": { "hotkey": "ControlLeft+AltLeft+KeyI", "delayed": true },
 21            "name": "右上",
 22            "icon": "north_east",
 23            "iconTheme": "material-symbols-rounded",
 24            "angle": 45
 25          },
 26          {
 27            "type": "hotkey",
 28            "data": { "hotkey": "ControlLeft+AltLeft+ArrowRight", "delayed": true },
 29            "name": "右半",
 30            "icon": "east",
 31            "iconTheme": "material-symbols-rounded",
 32            "angle": 90
 33          },
 34          {
 35            "type": "hotkey",
 36            "data": { "hotkey": "ControlLeft+AltLeft+KeyK", "delayed": true },
 37            "name": "右下",
 38            "icon": "south_east",
 39            "iconTheme": "material-symbols-rounded",
 40            "angle": 135
 41          },
 42          {
 43            "type": "hotkey",
 44            "data": { "hotkey": "ControlLeft+AltLeft+KeyC", "delayed": true },
 45            "name": "置中",
 46            "icon": "filter_center_focus",
 47            "iconTheme": "material-symbols-rounded",
 48            "angle": 180
 49          },
 50          {
 51            "type": "hotkey",
 52            "data": { "hotkey": "ControlLeft+AltLeft+KeyJ", "delayed": true },
 53            "name": "左下",
 54            "icon": "south_west",
 55            "iconTheme": "material-symbols-rounded",
 56            "angle": 225
 57          },
 58          {
 59            "type": "hotkey",
 60            "data": { "hotkey": "ControlLeft+AltLeft+ArrowLeft", "delayed": true },
 61            "name": "左半",
 62            "icon": "west",
 63            "iconTheme": "material-symbols-rounded",
 64            "angle": 270
 65          },
 66          {
 67            "type": "hotkey",
 68            "data": { "hotkey": "ControlLeft+AltLeft+KeyU", "delayed": true },
 69            "name": "左上",
 70            "icon": "north_west",
 71            "iconTheme": "material-symbols-rounded",
 72            "angle": 315
 73          }
 74        ]
 75      },
 76      "shortcut": "Control+Shift+Space",
 77      "shortcutID": "",
 78      "centered": false,
 79      "anchored": false,
 80      "hoverMode": false
 81    },
 82    {
 83      "root": {
 84        "type": "submenu",
 85        "name": "視窗進階",
 86        "icon": "view_column",
 87        "iconTheme": "material-symbols-rounded",
 88        "children": [
 89          {
 90            "type": "hotkey",
 91            "data": { "hotkey": "ControlLeft+AltLeft+KeyD", "delayed": true },
 92            "name": "左三分之一",
 93            "icon": "first_page",
 94            "iconTheme": "material-symbols-rounded"
 95          },
 96          {
 97            "type": "hotkey",
 98            "data": { "hotkey": "ControlLeft+AltLeft+KeyF", "delayed": true },
 99            "name": "中三分之一",
100            "icon": "vertical_align_center",
101            "iconTheme": "material-symbols-rounded"
102          },
103          {
104            "type": "hotkey",
105            "data": { "hotkey": "ControlLeft+AltLeft+KeyG", "delayed": true },
106            "name": "右三分之一",
107            "icon": "last_page",
108            "iconTheme": "material-symbols-rounded"
109          },
110          {
111            "type": "hotkey",
112            "data": { "hotkey": "ControlLeft+AltLeft+KeyE", "delayed": true },
113            "name": "左三分之二",
114            "icon": "align_horizontal_left",
115            "iconTheme": "material-symbols-rounded"
116          },
117          {
118            "type": "hotkey",
119            "data": { "hotkey": "ControlLeft+AltLeft+KeyT", "delayed": true },
120            "name": "右三分之二",
121            "icon": "align_horizontal_right",
122            "iconTheme": "material-symbols-rounded"
123          },
124          {
125            "type": "hotkey",
126            "data": { "hotkey": "ControlLeft+AltLeft+MetaLeft+ArrowLeft", "delayed": true },
127            "name": "上一個螢幕",
128            "icon": "arrow_circle_left",
129            "iconTheme": "material-symbols-rounded"
130          },
131          {
132            "type": "hotkey",
133            "data": { "hotkey": "ControlLeft+AltLeft+MetaLeft+ArrowRight", "delayed": true },
134            "name": "下一個螢幕",
135            "icon": "arrow_circle_right",
136            "iconTheme": "material-symbols-rounded"
137          },
138          {
139            "type": "hotkey",
140            "data": { "hotkey": "ControlLeft+AltLeft+Backspace", "delayed": true },
141            "name": "還原",
142            "icon": "settings_backup_restore",
143            "iconTheme": "material-symbols-rounded"
144          }
145        ]
146      },
147      "shortcut": "Control+Shift+Alt+Space",
148      "shortcutID": "",
149      "centered": false,
150      "anchored": false,
151      "hoverMode": false
152    }
153  ]
154}

套用方式：

1. 先完全結束 Kando（Kando 會在離開時把記憶體裡的設定寫回檔案、開著編輯會被覆蓋）。
2. 編輯 macOS 的設定檔 ~/Library/Application Support/kando/menus.json。若已有自訂選單，把 menus 陣列裡的兩個物件貼進去、不要整檔覆蓋。
3. 重新開 Kando。觸發鍵 Control+Shift+Space（進階組 Control+Shift+Alt+Space）若跟既有快捷鍵衝突，直接在 Kando 設定 GUI 改最保險。

對照表（方向 → Magnet 動作 → 快捷鍵）：

設定範例：自訂腳本叫出 Ghostty 執行（command 型）

command 型項目直接把指令交給作業系統執行，它本身不開終端機視窗。要「叫出 Ghostty 並在裡面跑腳本」，得用 Ghostty 的 -e 旗標開一個新視窗執行指定指令。下面這組放兩個需要看畫面的磁碟工具：mole（互動式清理 TUI）跟 disk-report（印出硬碟空間報告，安裝方式見該篇）。

兩個寫法的共同骨架是 ghostty -e zsh -lc "<腳本>; exec zsh"：

• zsh -lc：用 login shell 執行，載入 .zprofile / .zshrc 的 PATH（PATH 設定見新機基礎建設），mole 跟 ~/.local/bin 底下的腳本才解析得到。少了這層，Kando 走 /bin/sh、沒有自訂 PATH，會找不到指令。
• ; exec zsh：腳本結束後把視窗留在一個互動 shell。mole 退出或 disk-report 印完，畫面都還在，不會瞬間關掉。

 1{
 2  "root": {
 3    "type": "submenu",
 4    "name": "磁碟工具",
 5    "icon": "hard_drive",
 6    "iconTheme": "material-symbols-rounded",
 7    "children": [
 8      {
 9        "type": "command",
10        "data": {
11          "command": "/Applications/Ghostty.app/Contents/MacOS/ghostty -e zsh -lc \"mole; exec zsh\"",
12          "delayed": false,
13          "isolateProcess": false
14        },
15        "name": "mole 清理",
16        "icon": "cleaning_services",
17        "iconTheme": "material-symbols-rounded"
18      },
19      {
20        "type": "command",
21        "data": {
22          "command": "/Applications/Ghostty.app/Contents/MacOS/ghostty -e zsh -lc \"disk-report; exec zsh\"",
23          "delayed": false,
24          "isolateProcess": false
25        },
26        "name": "硬碟空間報告",
27        "icon": "monitoring",
28        "iconTheme": "material-symbols-rounded"
29      }
30    ]
31  },
32  "shortcut": "Control+Shift+KeyD",
33  "shortcutID": "",
34  "centered": false,
35  "anchored": false,
36  "hoverMode": false
37}

把上面這個物件加進 menus.json 的 menus 陣列（跟前面視窗那兩個並排，逗號分隔）。

兩個延伸調整：

• 純背景、不用看畫面的腳本：不必開 Ghostty，command 直接寫 zsh -lc "$HOME/.local/bin/某腳本" 就好，腳本在背景跑完無聲結束。
• 若 ghostty 二進位路徑直接呼叫沒反應（Ghostty 已在執行時偶有此狀況）：改用 open -na Ghostty --args -e zsh -lc "mole; exec zsh"，強制由 open 帶起一個新視窗。

我的自訂模式紀錄

（待補：實際用了一段時間後保留與淘汰的項目、其他組選單的 JSON、踩到的坑。）

一個 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 的不同位置甚至各用一種。

腳本的做法是對每個 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 等近二十年的語法都用不了。

正確做法是用 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，直到找到具體的檔案或目錄。

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 聚合佔用報告。

目前推薦使用 Ed25519 演算法，相比 RSA 更安全、金鑰更短、驗證速度更快：

1ssh-keygen -t ed25519 -C "your_email@example.com"

若需相容較舊的系統（不支援 Ed25519），可退而使用 RSA-4096：

1ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

產生時會提示設定 passphrase（密碼短語），強烈建議設定。即使私鑰外洩，攻擊者仍需要密碼才能使用。

1. 寫入金鑰檔案

macOS / Linux

1cat > ~/.ssh/<key_name> << 'EOF'
2（貼上金鑰內容）
3EOF

'EOF' 加單引號 → 防止 shell 解析內容中的特殊字元（如 $、`）

Windows（PowerShell）

1New-Item -Path "$env:USERPROFILE\.ssh" -ItemType Directory -Force
2Set-Content -Path "$env:USERPROFILE\.ssh\<key_name>" -Value @"
3（貼上金鑰內容）
4"@

Windows 的 SSH 金鑰預設路徑為 C:\Users\<使用者>\.ssh\

2. 設定權限

macOS / Linux

1chmod 600 ~/.ssh/<key_name>

chmod 600 → 僅擁有者可讀寫，SSH 要求私鑰權限不可過於開放，否則會拒絕使用。

Windows（PowerShell，以系統管理員執行）

1icacls "$env:USERPROFILE\.ssh\<key_name>" /inheritance:r /grant:r "$($env:USERNAME):(R)"

Windows 需透過 icacls 移除繼承權限，並限制為只有當前使用者可讀取。 若權限過於開放，OpenSSH 同樣會拒絕載入金鑰。

3. 加入 SSH Agent

macOS

1# 啟動 agent（通常 macOS 已自動啟動）
2eval "$(ssh-agent -s)"
3
4# 加入金鑰，並存入 Keychain 避免重開機後失效
5ssh-add --apple-use-keychain ~/.ssh/<key_name>

若要讓金鑰在每次登入時自動載入，可在 ~/.ssh/config 中加入：

1Host *
2  AddKeysToAgent yes
3  UseKeychain yes
4  IdentityFile ~/.ssh/<key_name>

Linux

1# 啟動 agent
2eval "$(ssh-agent -s)"
3
4# 加入金鑰
5ssh-add ~/.ssh/<key_name>

Linux 重開機後 agent 會重置。可將 eval "$(ssh-agent -s)" 加入 ~/.bashrc 或 ~/.zshrc 讓它自動啟動。

Windows（PowerShell，以系統管理員執行）

1# 啟用 ssh-agent 服務（預設為停用）
2Get-Service ssh-agent | Set-Service -StartupType Automatic -PassThru | Start-Service
3
4# 加入金鑰
5ssh-add "$env:USERPROFILE\.ssh\<key_name>"

Windows 的 ssh-agent 是系統服務，啟用後重開機也會自動執行，不需額外設定。

4. 測試連線

三個平台指令相同：

1ssh -i ~/.ssh/<key_name> -T git@<host>

Windows 請在 PowerShell 或 Git Bash 中執行，路徑會自動對應到 $env:USERPROFILE\.ssh\。

備註

安全性建議

優先使用 Ed25519

為私鑰設定 Passphrase

1# 為已存在的金鑰補設或更換 passphrase
2ssh-keygen -p -f ~/.ssh/<key_name>

即使私鑰檔案被他人取得，沒有 passphrase 就無法使用。搭配 SSH Agent 後只需輸入一次，不影響日常使用體驗。

定期輪換金鑰

建議每 1-2 年輪換一次 SSH 金鑰。可在金鑰名稱中加入年份作為提醒，例如 id_ed25519_2026。

其他注意事項

• 不要將私鑰上傳到雲端同步服務（如 iCloud、Google Drive、OneDrive），除非經過加密
• 不要在多台機器之間複製同一把私鑰，應為每台機器各自產生獨立金鑰
• 避免使用已棄用的 DSA 金鑰，部分新版 OpenSSH 已預設拒絕 DSA
• ~/.ssh/ 目錄本身權限應為 700，authorized_keys 應為 600

常見問題排查

Permission denied (publickey)

1. 確認私鑰權限：chmod 600 ~/.ssh/<key_name>
2. 確認 ~/.ssh/ 目錄權限：chmod 700 ~/.ssh
3. 確認上傳的是 公鑰（.pub）而非私鑰
4. 使用 verbose 模式查看詳細錯誤：ssh -vvv user@host

Agent 中沒有金鑰

1# 確認 agent 是否正在運行
2ssh-add -l
3
4# 如果顯示 "Could not open a connection to your authentication agent"
5eval "$(ssh-agent -s)"
6ssh-add ~/.ssh/<key_name>

金鑰類型被伺服器拒絕

部分較新的伺服器已停用 DSA 和較短的 RSA 金鑰。檢查方式：

1ssh -vvv user@host 2>&1 | grep "Offering"

如果你的金鑰類型不在伺服器接受的清單中，需要重新產生 Ed25519 金鑰。

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）

取消勾選

登出並重新登入你的帳號

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