日常指令的現代替代品

• 現代 CLI 替代工具 — grep → ripgrep、find → fd、cat → bat、ls → eza，加上互動式模糊搜尋 fzf。什麼情境值得換、換了要注意什麼、為什麼別在腳本裡依賴它們。

終端機圖形化介面（TUI）

這一類「圖形化」是用製圖字元畫出來的介面，而不是把 PNG／JPG 渲染進終端機，所以傳輸量小、在低頻寬與手機連線下最穩。大致分六類：

• TUI 監控與儀表板 — btop / htop / k9s / ncdu 等系統監控的全螢幕互動介面；版控專用的 git 線圖工具（tig / lazygit / gitui）是同類 TUI 但獨立的子題。
• ASCII 與文字圖表 — gnuplot / termgraph / plotext 等把資料畫成終端機圖表的工具。
• 終端機多工器 — tmux / zellij，分割畫面、連線斷了 session 還在。
• 檔案管理器 — broot（樹狀）/ yazi / ranger（Miller 欄狀），像 IDE 側邊欄那樣瀏覽目錄與預覽檔案。
• SQL 客戶端 — harlequin（IDE 風）/ lazysql（瀏覽器風）/ pgcli、litecli（增強 REPL），在終端機連資料庫跑查詢。
• 訊息佇列客戶端 — Kafka 的 kaskade / yozefu / ktea（全螢幕 TUI）、Redis 的 iredis（增強 REPL），在終端機連 broker 瀏覽 topic 與訊息。

這個系列的每篇文章都用實機驗證導向的流程生產（裝起來實跑、TUI 交人互動驗、驗不了的標 caveat）。要擴展新類別時，照 驗證導向的 CLI 工具文章生產流程 走。

跟工具選單其他子系列的邊界

CLI 環境工具跟 tools 底下另外兩個子系列的分界：

多工器（tmux / zellij）與檔案瀏覽（broot / yazi）這類工具兩邊都會提到：本系列講它們在純終端機下的用法與選型，遠端 / 圖形的情境應用則由 remote / gui 兩系列承接。這些工具的配置檔怎麼版控、跨機器同步，見 Dotfile 管理 的終端機與編輯器模組。

底下自動列出本系列的所有文章、依日期排序。

選型的真正軸線：整合度 vs 組裝自由度

桌面環境的選擇，核心不是「輕或重」，是別人幫你整合好多少、你保留多少自己組裝的自由。這條軸線的一端是 GNOME 這種高整合方案：面板、設定、通知、檔案管理全部設計成一致的整體，你開機就有一台能用的機器，代價是想改動它預設的行為要對抗它的設計哲學。另一端是 Hyprland 這種 compositor：它只負責畫面與視窗，面板、啟動器、鎖屏、通知你全部自己挑自己接，代價是要花時間組裝、每個元件都要自己維護。

「輕/重」只是這條軸線的副產品。高整合方案因為要保證所有元件協同，通常帶較多常駐服務、吃較多記憶體；自己組裝的方案可以只裝你要的，所以輕——但如果你把面板、啟動器、通知、鎖屏一個個補齊，最後的資源佔用未必比一個現成 DE 省多少。所以判選型別問「哪個輕」，要問「我想花多少時間在組裝與維護、換到多少客製自由」。

五個主流選項的定位

下表是常見選項在「整合度」這條軸線上的位置與代價。每個選項底下有延伸說明，因為同樣一句「適合客製」在不同方案裡的實際體驗差很多：

GNOME：把選擇替你做完的現代桌面

GNOME 的定位是「一套有明確設計主張的完整桌面」——它預設一個不同於 Windows/macOS 的工作流（頂欄 + Activities 總覽 + 動態工作區），並且刻意收斂可調選項，讓多數人不用設定就有一致體驗。從 Windows/macOS 轉來、想要「裝好就能用、不想折騰」的人，GNOME 是穩妥選擇：它的整合度最高，通知、設定、線上帳號、檔案管理彼此協調。

代價在客製。GNOME 把很多設定收進 extension 或需要另裝 gnome-tweaks（Arch：pacman -S gnome-tweaks）才改得動的角落，想把它調成傳統工作列風格是在對抗它的設計方向，而 extension 又會隨 GNOME 大版本更新而失效。所以 GNOME 適合「接受它的工作流」的人，不適合「想按自己習慣重排一切」的人。資源上它是這幾個裡偏吃的，老硬體上會感覺得到。

KDE Plasma：整合度高、但幾乎每個角落都能調

KDE Plasma 少見地同時做到高整合與高可調：它像 GNOME 一樣開箱即用、元件協調，但幾乎每個行為都攤在設定介面裡讓你改——面板可以拆解重組、視窗規則、快捷鍵、視覺效果都有深度選項。從 Windows 轉來的人會覺得它的預設隱喻（底部工作列 + 開始選單）親切，又保留了往下鑽的空間。

它的代價不在資源（現代 Plasma 已相當精實，中階機器順暢），在「選項多到需要自己收斂」——設定深意味著你可能花很多時間在調整上。想要「高整合又想保留大量客製、但不想從零組裝」的人，Plasma 通常是比 GNOME 和 Hyprland 都平衡的落點。它的 Wayland session 近年已是預設且成熟。

XFCE：老硬體與「要傳統、要穩、要輕」的預設

XFCE 的定位是輕量而傳統：它給你熟悉的桌面隱喻（工作列、選單、系統匣），資源佔用在這幾個裡最低，且以穩定少變著稱——它不追新，多年來介面與行為變動小。老硬體、低階 VM、或「我只要一個不吵不鬧、能穩定工作的桌面」的場景，XFCE 是可靠預設。

它的取捨是現代感與顯示協定：XFCE 目前仍以 X11 為主，Wayland 化在進行但尚未是預設，所以想要 Wayland 的分數效益（見下節）目前要往別的方案找。客製自由度中等——比 GNOME 開放、但沒有 KDE 那種深度設定，也沒有 Hyprland 那種完全重組的自由。

Cinnamon：給「要 Windows 式熟悉感」的轉移者

Cinnamon 出身 Linux Mint，定位是把傳統桌面隱喻做得順手好上手——底部工作列、開始選單式的應用選單、系統匣，對從 Windows 轉來的人幾乎零學習曲線。它比 XFCE 現代一點、視覺完整度高一些，整合度也高（自帶檔案管理員 Nemo、設定中心、特效）。

代價與 XFCE 類似：以 X11 為主，資源比 XFCE 略高。它適合「要一台立刻上手、像 Windows 但是 Linux」的工作機，不適合追求 Wayland 或極致輕量的場景。附帶一提，Cinnamon 的檔案管理員 Nemo 假設 Cinnamon 桌面服務在旁邊，把它單獨裝進裸 window manager 會拖進整套 Cinnamon 元件——這正是加圖形檔案管理員那篇講的桌面環境耦合。

Hyprland：不是 DE，是你自己組一個桌面

Hyprland 嚴格說不是桌面環境，是一個平鋪式（tiling）Wayland compositor——它只負責畫面合成與視窗排列，面板、啟動器、鎖屏、通知、桌布、音量控制全部不含，要你自己挑元件接上去。選它意味著你接受「從零組裝一個桌面」這件事，換來的是最高的客製自由（每個元件都你選、佈局規則完全你定）和最低的裸資源佔用。

它適合「把配置桌面當成一種投入、想要一套完全長成自己樣子的環境」的人，不適合「只想裝好開始工作」的人。組裝過程本身有相當的學習曲線與維護成本——這也是為什麼本系列用一整個 Rice 設計模組談「選了 Hyprland 之後怎麼把它組起來」。如果你還在「要不要走這條路」的階段，這篇就是那個模組的上游：先確認你要的是組裝自由、而不是開箱即用。

Wayland vs X11：選型時避不開的底層判斷

顯示協定是選型時的一條隱形軸線，因為它決定了一部分未來相容性。Wayland 是較新的顯示協定，設計上更安全、對高 DPI 與多螢幕不同刷新率支援更好，是 Linux 桌面的方向；X11 是沿用數十年的舊協定，相容性最廣但架構老舊、社群維護逐漸收斂到維持模式。GNOME、KDE Plasma、Hyprland 都已預設或原生 Wayland；XFCE、Cinnamon 目前仍以 X11 為主。

實務判讀：如果你用 NVIDIA 專有驅動、或依賴某些只支援 X11 的老工具（部分螢幕錄製、遠端桌面、自動化工具），X11 方案目前可能更少驚喜；如果你要高 DPI 筆電、多螢幕混合刷新率、或想跟上長期方向，優先選 Wayland 方案。這不是非此即彼的道德選擇，是看你的硬體與工具鏈落在哪邊。

依情境選：從你的處境倒推

選型的最後一步是把上面的定位對回你自己的處境，不是背「哪個最好」：

• 剛從 Windows/macOS 轉來、只想要能用：KDE Plasma（熟悉隱喻 + 之後可深調）或 GNOME（接受新工作流、要最省心）。要極致熟悉感就 Cinnamon。
• 老硬體 / 低階 VM / 要穩定不折騰的工作機：XFCE。資源最低、變動最少。
• 想把桌面調成完全自己的樣子、願意投入組裝：Hyprland（或其他 WM）。先讀 Rice 設計模組 確認你要的是這條路。
• 要高整合又要大量客製、不想從零組裝：KDE Plasma，是這兩個需求的平衡點。
• 硬體是 NVIDIA 或依賴 X11 工具：優先 X11 成熟的方案（XFCE / Cinnamon），或確認你的 Wayland 方案在該硬體上的狀況再決定。

判準是把「我願意花多少時間在桌面本身、我對客製的需求有多強、我的硬體與工具落在 Wayland 還是 X11」三個問題答清楚，選項自然收斂。沒有一個 DE 對所有人最好——選錯最常見的原因是拿別人的推薦套自己不同的處境。

桌面環境的擴充生態

選好 DE 之後，各方案還有自己的擴充路徑，這是「選項之下還有選項」的一層：

• GNOME：透過 GNOME Extensions 加面板、工作流、狀態列元件，但要注意 extension 綁 GNOME 版本、大版本更新可能失效。
• KDE Plasma：內建的 widget（plasmoid）、全域主題、視窗規則系統，多數擴充不需要離開設定介面。
• XFCE / Cinnamon：panel plugin、applet、主題，擴充幅度中等但穩定。
• Hyprland：因為本來就是自己組，擴充等於換元件——換 bar（waybar/其他）、換啟動器、換通知 daemon，自由度最高也最需要自己維護。這一整套怎麼組，是 Rice 設計模組 的主題。

下一步

• 選了 Hyprland、要開始組裝：Dotfile 管理：桌面 Rice 設計 是「選了之後怎麼把它長成自己的樣子」的完整模組。
• 桌面選好、要裝檔案管理員這類 GUI app 時的相依判讀：在 Hyprland 加圖形檔案管理員。
• 純終端機環境不需要桌面環境、但需要對應的 CLI 工具：CLI 環境工具。
• 桌面裝好後遇到顯示、鎖屏、服務層的問題怎麼診斷：除錯與診斷。

這篇按「你原本用什麼」對照現代替代品，講清楚每個替代品解掉原工具的什麼痛點、什麼情境值得換、以及換了要注意的地方。核心的搜尋三件套（ripgrep / fd / fzf）值得優先掌握，其餘按需採用。

搜尋文字內容：grep → ripgrep（rg）

ripgrep（指令是 rg）是 grep 的現代替代品，最大差別在它預設就做了開發者幾乎每次都要的事：遞迴搜尋當前目錄、尊重 .gitignore（不會翻進 node_modules、.git、build 產物）、自動跳過二進位檔、輸出帶顏色與行號。用 grep 搜整個專案常要寫 grep -rn --exclude-dir=node_modules pattern .，用 rg pattern 一句就到位且更快（Rust 實作 + 平行搜尋）。

什麼情境值得換：在專案目錄裡找程式碼、找字串出現在哪些檔案——這是 rg 最省力的地方。什麼時候還是用 grep：處理 pipe 進來的串流（command | grep x）兩者差不多；寫要在任何機器都能跑的腳本時 grep 是保證存在的（rg 要另外裝）。注意點：rg 預設跳過 .gitignore 忽略的檔，要搜被忽略的檔案得加 -u（或 -uu 連隱藏檔一起）。

找檔案：find → fd

fd 是 find 的現代替代品，把 find 那套冗長語法換成直覺的用法。find . -name '*.md' -type f 用 fd 是 fd -e md；fd pattern 直接對檔名做模糊比對，一樣預設遞迴、尊重 .gitignore、跳過隱藏檔、輸出帶色。速度也快得多。

什麼情境值得換：日常找檔案（「這個 config 檔在哪」「有哪些 .test.ts」）。什麼時候還是用 find：find 的 -exec、複雜的時間 / 權限 / 大小條件組合仍然更全面，寫可攜腳本時 find 保證存在。注意點：fd 的正則 / glob 預設是 smart case（有大寫才區分大小寫），跟 find 的精確比對行為不同。

互動式模糊搜尋：fzf（不是替代，是加一層）

fzf 不替代任何工具，它是一層互動式模糊選擇器，把「一堆候選 → 你挑一個」這件事變得極快。它從 stdin 吃候選清單、開一個可即時模糊過濾的介面、把你選的印到 stdout，所以能跟任何產生清單的指令組合：fd -e md | fzf 挑一個 markdown 檔、git branch | fzf 挑分支、rg --files | fzf 挑檔案開。

最高價值的兩個內建整合：Ctrl+R 覆寫 shell 的歷史搜尋（模糊搜尋整個命令歷史，比預設的反向搜尋強太多）、Ctrl+T 把檔案路徑插進當前命令列。這兩個 key binding 不是裝完自動生效的，要在 shell 設定裡啟用——新版 fzf 直接在 .zshrc / .bashrc 加一行 eval "$(fzf --zsh)"（bash 用 --bash）；舊版則 source 套件附的整合檔（Arch 在 /usr/share/fzf/key-bindings.zsh 與 completion.zsh，路徑隨發行版不同）。沒加這行，Ctrl+R 不會有反應。fd 跟 rg 可以當 fzf 的預設來源，三者是一組。

看檔案內容：cat → bat

bat 是 cat 加上語法高亮、行號、Git 修改標記、自動分頁。看程式碼 / 設定檔時比 cat 好讀很多。bat file.py 直接帶高亮顯示。

什麼情境值得換：人在終端機讀檔案內容。什麼時候還是用 cat：把檔案內容 pipe 給其他程式、或在腳本裡——這時要純內容，用 cat（bat 在偵測到輸出不是終端機時會自動退化成類 cat 行為，但明確用 cat 更穩）。注意點：bat 預設會分頁（走 less），在腳本 / pipe 情境要加 --paging=never 或 -pp。

列目錄：ls → eza

eza（exa 的維護接棒者）是 ls 的現代替代品，預設輸出帶顏色與圖示、更好的欄位對齊、內建 Git 狀態欄、--tree 直接畫樹狀。eza -la --git 一眼看到權限、大小、修改時間、Git 狀態。

什麼情境值得換：人在終端機瀏覽目錄。什麼時候還是用 ls：腳本裡解析輸出用 ls 更穩定（現代替代品的欄位格式可能隨版本變），可攜腳本 ls 保證存在。

其他常見替代

按需採用，痛點對上了再裝：

有兩個替代品的那幾格，差別不是「新舊」而是不同的使用模型，值得分清楚：

• du 的 ncdu vs dust：兩者解的動作不同。ncdu 是互動式的——它掃一次目錄，開一個能逐層往下鑽、當場按鍵刪檔的介面，是「磁碟滿了、要找出並清掉大檔」這個任務的正典（清空間邊找邊刪）。dust 是一次性的——跑完印一張樹狀 + 長條的靜態報告，適合「快速看一眼誰佔空間」而不打算就地刪。要清理用 ncdu，要瞄一眼用 dust。
• top 的 htop vs btop：htop 是輕量、幾乎每台機器都該有的安全預設——彩色、可捲動、能直接對 process 送訊號，資源佔用極低，SSH 進一台陌生機器臨時看負載首選它。btop 是更完整的全螢幕儀表（CPU / 記憶體 / 網路 / 磁碟的圖形化面板），好看資訊多，但相對重、依賴多；當常駐監控台用很讚，臨時排查用 htop 更快到位。TUI 監控工具的完整比較見 TUI 監控工具。

採用策略與注意事項

優先順序：搜尋三件套（rg / fd / fzf）投報率最高，每天用幾十次、學習成本低，先裝這三個。bat / eza 是體驗提升，其餘按痛點採用。

跨機器 / CI 的腳本別依賴它們：要在別台機器或 CI 跑的腳本，用保證存在的 grep / find / cat，因為現代替代品不一定裝了。專案內部、已宣告了 dev 依賴的腳本（devcontainer、Makefile）另當別論——那裡明確裝了 rg / fd，用它們（甚至還因為 rg 尊重 .gitignore 的語意才選它）很合理。分界是「這段腳本會在沒裝這些工具的環境跑嗎」，不是「腳本一律不能用」。

安裝：多數在各發行版套件庫直接有。Arch：pacman -S ripgrep fd fzf bat eza zoxide，按需再加 procs ncdu htop git-delta（delta 的套件名是 git-delta）。Debian / Ubuntu 有兩個要注意的改名坑——fd 的執行檔在 apt 上叫 fdfind、bat 叫 batcat（都是為了避免跟既有套件撞名），要自己 alias 回 fd / bat；eza 較舊的 apt 源可能還沒有，用 cargo 或官方 repo 裝。macOS 用 brew install ripgrep fd fzf bat eza zoxide。裝好後它們該進你的 dotfile 套件清單，新機器 bootstrap 時一次裝齊。

相關

• 這篇是「日常指令替代」；全螢幕 TUI 工具（監控、Git、檔案瀏覽、資料庫）見 CLI 環境工具 的其他文章。
• 為什麼把工具當成「有取捨的選項」而非唯一答案，見 工具選單總覽。
• 這些工具進 dotfile 套件清單、一鍵安裝的做法，見 模組八：Bootstrap script 與套件清單。

這篇講的是一套判讀紀律，不是某個特定工具。後面幾篇（遠端連線與終端機問題、機器連不到或起不來、程序、服務與狀態怎麼判）是這套紀律在各種具體情境的應用。

表象會騙人：一個判斷被畫面帶偏兩次的實例

一個具體案例最能說明為什麼不能靠肉眼。在一次桌面 shell（畫桌面 UI 的圖形程式，不是 bash/zsh 那種命令列 shell）的除錯裡，畫面中央出現一個「輸入密碼」的覆蓋層，配著時鐘、天氣、通知的整片儀表板。第一眼的判斷很自然：螢幕被鎖住了。

接著幾個看似合理的檢查反而把判斷帶得更偏：loginctl 查不到這個 session 的 LockedHint、pgrep 找不到任何獨立的鎖屏程式、那個 shell 的 CLI 也沒有 lock 指令。三個訊號湊起來，得出一個「更正」的結論：這不是真的鎖，只是一個長得像鎖屏的儀表板面板。

這個「更正」是錯的。真正定案是靠讀那個 shell 自己寫的 log：log 裡明明白白有鎖屏模組被載入、有 idle 計時器在數秒數、時間到就觸發鎖定。它是一個真的螢幕鎖，走的是 Wayland 的 session-lock 協議。

為什麼前面三個檢查會誤導？因為它們讀的是錯的權威來源。loginctl 的 LockedHint 是 logind（systemd 的登入管理）那一層的鎖定狀態，而這個鎖走的是 Wayland 合成器（compositor，負責把視窗合成到螢幕、管輸入輸出的核心程式）那一層的協議，兩者是獨立機制——查 logind 對合成器層的鎖天生查不到，不是「沒鎖」，是查錯地方。pgrep 找不到獨立程式，是因為鎖屏畫面由 shell 主程式在自己的行程內畫，本來就沒有另一個可執行檔可抓。真正記錄「有沒有鎖、為什麼鎖」的權威來源，是那個 shell 的 log；讀到它，一次就定案。

肉眼加上讀錯層的檢查，猜錯了兩次；讀對權威來源，一次就對。教訓不是「那些工具沒用」，是要先確認你讀的是不是這件事的權威狀態。

每種問題都有它的權威狀態來源

除錯的第一步，是為眼前的現象找到記錄它的權威來源。不同類別的問題，權威來源不同：

這張表的用法不是背它，是養成一個反射：看到現象先問「這件事的權威狀態記在哪張表裡」，再去讀那張表，而不是從畫面推測。下面幾個常見的判錯，都是讀了表象而不是權威來源。

讀對權威來源、但查詢條件要對

有時權威來源對了，還是會被誤導——因為查詢的條件寫錯。判程式活著沒，行程表是對的權威、pgrep 是對的工具，但你得比對它實際的行程名：一個程式可能以 symlink 的短名在跑，用你以為的名字 pgrep 就掃不到、誤判成掛了。判服務由誰提供，權威是服務註冊表而非畫面（送一則通知看畫面有沒有跳不可靠——沒跳可能是勿擾吃掉或根本沒送出）。這兩類的具體查法（pgrep -x、busctl 查 D-Bus 擁有者）見 程序、服務與狀態怎麼判。重點是：權威來源對，還要問對地方、用對條件。

卡住是資源問題還是相容問題：先看資源，別先怪相容性

一個耗時的操作中途停住時，很容易直接跳到「是不是這個平台不相容 / 這個東西在這台機器上跑不起來」。但這個結論成本很高（可能讓你放棄一條其實可行的路），而它的權威狀態很好查。一次原始碼編譯跑到一半停住，第一個該看的是資源：df -h 看磁碟是不是滿了、記憶體是不是被吃光——一次實際的案例就是主機磁碟寫滿把編譯中途打斷，清出空間後同一份原始碼接著編就過，跟平台相容性完全無關。先讀資源狀態排除掉最廉價的解釋，再去懷疑相容性這種昂貴的結論。

讀程式自己的 log：從症狀往上游找

當現象是「某個程式行為不對」，它自己的 log 幾乎總是比終端機捲過的畫面更接近真相。很多程式在終端機只印一段摘要，卻同時把詳細執行紀錄寫進一個 log 檔或系統日誌；當畫面上的訊息不足以定位時，那份 log 裡往往就有明確答案。

找 log 的常見去處：程式自己的 log 檔（常在 ~/.local/state/<程式>/ 或 ~/.cache/<程式>/ 底下）、systemd 服務的 journalctl -u <服務名>、或程式啟動時印出的 log 路徑。找到之後，關鍵是用症狀當關鍵字往上游搜——grep -iE 'error|fail|not found|does not exist' <log> 挑出異常行，或在 less 裡用 ?pattern 往回找「第一個」異常（不是停在最後一個下游錯）。一個指令因為前面某個檔案不存在而失敗，終端機可能只報一個看似無關的下游錯誤，但 log 裡會有那句 File does not exist 直指源頭。一個實際案例：某 shell 換了配色卻沒生效，畫面上什麼錯都沒有，是它的 log 裡一句「讀取 scheme 檔失敗：檔案不存在」點出根因——原來那個檔在 shell 啟動當下還沒被建出來。畫面沉默，log 說話。

這一層跟 可除錯的 bootstrap 是一體兩面：那篇談怎麼讓你自己寫的腳本產生一份可診斷的 log，這裡談除錯時怎麼去讀程式自己的 log。兩邊的共同紀律是：不要只盯著終端機捲動，去找那份持久的、詳細的權威紀錄。

遠端除錯反而逼出好紀律

透過 SSH 遠端除錯時，你看不到那台機器的畫面——這個限制反而是好事。看不到畫面，你就沒得靠肉眼猜，只能去讀權威狀態：查 log、查服務註冊、查行程表、查資源。很多在本地會犯的「看畫面就下結論」的錯，在遠端因為根本沒畫面可看而自動被避開。

反過來說，在本地（或看得到畫面的 VM）除錯時，畫面的存在是個誘惑：它讓你以為看到了就懂了。前面那個鎖屏誤判，正是發生在「看得到畫面」的情境——畫面上的密碼框太有說服力，反而蓋過了去讀 log 的動作。把遠端那套「沒有畫面、只信權威狀態」的紀律，也用在本地，就不會被畫面帶偏。

判讀紀律：四步

把上面的東西收成一套每次都能跑的流程：

1. 描述症狀：現象是什麼，先講清楚，不要在這步就急著下結論（「畫面出現密碼框」，不是「螢幕鎖了」）。
2. 定位權威來源：這件事的權威狀態記在哪——log、服務註冊、logind / systemd、行程表、資源用量（用上面那張表對照）。
3. 用對的工具讀它：讀那個權威來源，不是讀畫面、不是讀終端機捲過的殘影。
4. 權威跟表象矛盾時，信權威：如果讀到的權威狀態跟你肉眼的第一印象打架，信權威狀態、回頭修正第一印象——那個矛盾點通常就是你原本會猜錯的地方。

這套流程的價值不在任何單一工具，在於它讓你的判斷有一個可回溯的依據，而不是一串越猜越偏的直覺。

下一步

• 這套心法在遠端連線與終端機情境的應用，見 遠端連線與終端機問題。
• 機器連不到、或根本起不來時怎麼從權威狀態往下查，見 機器連不到或起不來。
• 程序在不在、服務歸誰、狀態怎麼判的具體招式，見 程序、服務與狀態怎麼判。
• 怎麼讓你自己的 bootstrap 腳本產生可讀的 log，見 可除錯的 bootstrap。

連線層：從 SSH 出發，按弱點往上補

連線層的基準是 SSH——它是遠端登入的通用標準，加密、認證、port forwarding 都靠它，多數情況直接用 SSH 就夠。往上補工具的時機，是 SSH 在特定弱點上讓你難受的時候，而不是「有更潮的工具就換」。SSH 的兩個典型弱點是「網路一換就斷」（筆電休眠、Wi-Fi 換點、行動網路切換）和「連線中斷後要手動重連」，mosh 與 autossh 各補一個。

mosh：換網路不掉線、高延遲下還能打字

mosh（mobile shell）解的是「連線的存活與手感」：它在 SSH 之上用 UDP 維持一個跟客戶端 IP 無關的 session，所以你的筆電從家裡 Wi-Fi 換到行動網路、或休眠喚醒換了 IP，連線不會斷。它還做本地回顯預測，高延遲鏈路上打字不會有一個字一個字等回應的黏滯感。從咖啡廳、通勤、跨國高延遲連遠端時，mosh 的體驗明顯優於裸 SSH。

它的代價是走 UDP，要在遠端開一段 UDP port 範圍（防火牆/雲端 security group 要放行），且不做 SSH 的 port forwarding——需要轉發本地端口時還是得另開一條 SSH。所以 mosh 通常跟多工器搭配用：mosh 保住連線手感、多工器保住 session 內容，兩者互補。

autossh：維持一條會自己重連的隧道

autossh 解的是「隧道的自動存活」：它監控一條 SSH 連線，斷了就自動重建，適合需要長期維持的場景——例如把遠端某個服務 port forward 回本地、或維持一條反向隧道讓 NAT 後的機器可被連入。它本身只負責「重連」這個動作，重連後你原本的工作是否還在，取決於你有沒有用多工器把 session 保住。

判讀：autossh 是「基礎設施型」工具，用在你要一條無人值守、掉了要自己回來的隧道；日常互動式登入用 mosh 的漫遊能力更順。兩者不衝突。

網路層：機器根本連不到時，先解可達性

前面的連線工具都假設「遠端機器的 IP 你連得到」。當遠端機器在 NAT 或防火牆後面、沒有公開 IP 時，連不到是可達性問題，要在網路層解，而不是換 SSH 客戶端。WireGuard 是現代的輕量 VPN 協定，讓兩台機器像在同一個私網裡直接互連；Tailscale 建在 WireGuard 之上，把「交換金鑰、打洞穿透 NAT、管理裝置清單」這些麻煩事自動化，通常裝好登入就能讓你的所有裝置互相 SSH，不必自己配 VPN。

判讀：家裡的機器、公司內網的開發機、雲端私網裡的主機，想從外面連進去又不想開公網 port 暴露 SSH，用 Tailscale（要省事）或自建 WireGuard（要完全自主、不依賴第三方協調伺服器）在網路層打通，之後 SSH/mosh 照常用。這一層跟連線層是疊加關係：先有可達性，上面才談連線手感。（機器連不到的診斷——是網路層、服務層還是機器沒起——見機器連不到或起不來。）

同步層：三種語義，依 workflow 選

檔案同步不是一個問題，是三種不同語義的問題，挑錯工具會很痛。核心差異在「同步是單向還是雙向、是一次性快照還是持續即時、檔案存在本地還是遠端」。rsync、sshfs、mutagen 各自代表一種語義：

rsync：單向增量，部署與拉回成果的正典

rsync 解的是「把一批檔案有效率地從 A 複製到 B」：它只傳有變動的部分（增量），可保留權限與時間戳，是單向的一次性動作——你下指令、它同步一次、結束。它適合明確的「推上去」或「拉回來」：把本地建好的東西部署到遠端、把遠端跑完的產出拉回本地、定期備份。它不做「持續盯著兩邊、誰改了就同步」，所以拿它當即時開發同步用會很累（每次改都要手動跑）。

因為單向且明確，rsync 也是三者裡最可預測、最不會意外覆蓋的——你清楚知道哪邊是來源、哪邊被更新。無人值守的成果回收（遠端跑完長任務、把結果 rsync 回本地）用它最穩。

sshfs：把遠端目錄當本地資料夾掛載

sshfs 解的是「我想用本地的工具存取遠端的檔案、但不想先複製下來」：它透過 SSH 把遠端目錄掛載成本地的一個路徑，你用本地的編輯器、檔案管理員直接開，實際檔案仍只在遠端。適合偶爾存取、檔案不宜落地到本地的場景。

它的代價是脆與慢：每次存取都走網路，延遲高時開大目錄、跑 git status 這種大量小檔操作會很卡；連線一斷，掛載點就進入壞狀態要重掛。所以 sshfs 適合「輕度、偶爾」的遠端存取，不適合當重度開發的主力——重度開發本地要有一份真的檔案，那是 mutagen 的場景。

mutagen：雙向即時，本地編輯遠端執行的開發迴圈

mutagen 解的是現代遠端開發最常見的迴圈：「在本地用順手的編輯器改、在遠端（有算力、有環境、有相依）執行」，它在兩邊各保留一份實體檔案並持續雙向即時同步——你本地存檔，遠端幾乎同時更新；遠端產生的檔案也同步回本地。因為兩邊都是本地檔案，git status、搜尋、建置都快，沒有 sshfs 那種每次存取走網路的黏滯。

它的代價是多一個常駐同步 daemon 與初次設定，且雙向同步要處理衝突（兩邊同時改同一檔）。適合「本地機器弱/環境不對、但要在強遠端上跑」的長期開發關係。如果你的需求只是「偶爾拉個檔」，mutagen 是殺雞用牛刀，rsync 或 sshfs 更省。

IDE remote：把編輯器的執行環境整個搬到遠端

VS Code Remote（SSH/Containers/WSL）與 JetBrains Gateway 是另一條路線：它們不同步檔案，而是把編輯器的後端（語言伺服器、終端機、除錯器）整個跑在遠端，本地只留 UI。你在本地視窗編輯，但索引、建置、執行全發生在遠端那台機器上，檔案也只在遠端。這解掉了同步的衝突問題（沒有兩份檔案要對齊），代價是綁定該編輯器、且需要一條夠穩的連線維持 UI 與後端的通訊。

判讀：如果你本來就用 VS Code / JetBrains，remote 模式通常比自己接 mutagen + SSH 更省事、體驗更整合；如果你用終端機編輯器（Vim/Neovim/Emacs）或要編輯器無關的方案，走 mutagen（雙向同步）或直接在遠端多工器裡編輯（檔案只在遠端、靠多工器保住 session）。

在 Arch 上的安裝與依賴（實測 aarch64）

這些工具多數在官方 repo，但有幾個安裝陷阱與部署前提是實機才看得出來的，選好工具後要一起確認：

• mosh：官方 repo（pacman -S mosh）。同一套件同時含 client（mosh）與 server（mosh-server），所以遠端機器也要裝 mosh——遠端是別人的伺服器時這是前提；另外 UDP 埠範圍（預設 60000–61000）要在防火牆 / security group 放行。
• autossh / rsync / sshfs：都在官方 repo（pacman -S autossh rsync sshfs）。sshfs 會自動拉 fuse3 相依，不用手動裝 FUSE；掛載需要 /dev/fuse 可存取（一般環境已就緒）。
• tailscale：官方 repo（pacman -S tailscale），但裝完 daemon 預設沒起——要 sudo systemctl enable --now tailscaled 之後才能 tailscale up。少了這步，tailscale 指令會因 daemon 未運行而失敗。
• wireguard：裝 wireguard-tools（wg / wg-quick）。核心模組在多數發行版是 loadable module，wg-quick 會在需要時自動 modprobe wireguard，日常不用手動處理。
• mutagen：不在官方 repo，且 pacman -S mutagen 會裝到完全無關的 python-mutagen（音訊 metadata 函式庫）。正確安裝是 AUR 的 mutagen.io-bin（paru -S mutagen.io-bin），提供 mutagen 執行檔，aarch64 有官方 binary。這是「以為一句 pacman 就有、實際會裝錯東西」的典型坑。
• VS Code Remote / JetBrains Gateway：綁各自的 IDE，不透過套件管理器單獨裝，隨 IDE 的 remote 擴充啟用。

依情境選

把上面的工具對回你的實際處境：

• 日常從筆電連遠端、常換網路：mosh（漫遊）+ 多工器（保 session）。
• 要一條長期自動維持的隧道 / 反向連接：autossh + 多工器。
• 遠端機器在 NAT 後、根本連不到：先用 Tailscale 或 WireGuard 在網路層打通，再照常 SSH/mosh。
• 部署上去、或把遠端跑完的成果拉回來：rsync（單向、可預測）。
• 偶爾存取遠端幾個檔、不想複製下來：sshfs（掛載）。
• 本地編輯、遠端執行的長期開發迴圈：mutagen（雙向即時）或你的 IDE 的 remote 模式。
• 無人值守跑長任務、跑完自動回收成果：多工器保住任務 + rsync 拉回產出，見讓機器跑無人值守的長任務。

判準是先分清「你缺的是連線存活、可達性、還是檔案一致」，再在對應那一層挑工具——三層各挑各的，不要拿同步工具去解連線問題。

下一步

• 保住遠端 session 的多工器（tmux / zellij）配置與比較：遠端工具總覽 與 CLI 環境工具 的多工器篇。
• 連不上、終端機噴亂碼、要從 SSH 操控圖形桌面等連線本身的問題：除錯與診斷：遠端連線與終端機問題。
• 機器完全沒回應、域名解析不了、虛擬機起不來：機器連不到或起不來。
• 把遠端機器設成無人值守、離開後自己跑完長任務送回成果：讓機器跑無人值守的長任務。

這段地基平常被跳過，是因為多數人是在一台早就裝好的機器上開始管理 dotfile。但只要你換到全新環境——開一台 VM、租一台雲端主機、拿到一台空機器——就會直接撞上這層：安裝程式問你十幾個選項該怎麼選、裝完發現連 sudo 都沒有、想從本機連進去卻還沒有 SSH key。這些都不在編號模組的範圍，卻是跑 模組八的 bootstrap script 之前必須先過的關。

本系列的內容來自一次完整的 VM 實測：在 Apple Silicon 的 UTM 上從 archboot（Arch 的獨立網路安裝環境 ISO）裝 Arch Linux ARM、跑 dotfile 的 install.sh、一路把 Hyprland 桌面拉起來。實測中每個卡關點都被記錄下來，這裡把它們蒸餾成可重用的判讀與決策，不綁特定發行版或虛擬化軟體。

在學習路徑中的位置

模組零的操作順序指引 列出從 OS 安裝到桌面就緒的完整依賴鏈，但只把「安裝作業系統」標成一步。本系列是那一步的展開：安裝程式每個選項背後的取捨、裝完之後的驗證、以及連入機器的幾種路徑。

文章

機器裝好、能連入之後若出問題（連不上、終端機亂、程式行為怪），除錯與診斷自成一組，見同層的 Linux 除錯與診斷。

依情境的讀法

主線那幾篇照「安裝 → 驗證 → 連入 → 可除錯 → 無人值守」的順序，是「從零開一台新機器、到讓它自己跑活」的完整路線，但不是每個讀者都從零開始：

• 接手一台別人已裝好的機器：OS 已經在，從 最小安裝後的工具驗證與補足 切入，確認它缺不缺你流程要的工具。
• 雲端主機初始化：雲端主機多半已附 OS image、已有 sudo 與注入的 key，適用的是 外部連入、SSH key 與無 key 的 bootstrap 路徑 跟 可除錯的 bootstrap，前兩篇的 ISO 安裝可略過。
• bootstrap 失敗來 debug：直接讀 可除錯的 bootstrap，它也涵蓋「腳本不是你寫的、只想 debug 一次失敗」的情況。
• 讓機器無人值守跑活：機器已能連入操作，只想設好讓它在你離開後自己跑長任務或 agent，直接讀 讓機器跑無人值守的長任務。
• 遇到問題要除錯：機器已在跑但出狀況（連不上、終端機亂、程式行為怪），進 Linux 除錯與診斷，從 診斷心法 建立判讀紀律，再依症狀分流。
• 裝好後想讓它自己顧：服務跑起來後，主動確認這台有沒有在監控自己的服務死活（systemctl show sshd -p OnFailure），沒有就從最簡單的 OnFailure + ntfy 建起——遠端機器至少把 sshd 掛上，掛了就失聯。見 服務掛了怎麼自動知道。

跟其他模組的交叉引用

• 模組八：Bootstrap script 設計——本系列是它的前置；bootstrap 假設套件清單完整、機器可連入，本系列補「在那之前」。
• 模組五：Hyprland VM 測試——本系列的 VM 安裝是它的下游前置；裝好機器才能測 Hyprland。
• 模組七：日誌判讀與診斷工具——「可除錯的 bootstrap」與它呼應：前者談怎麼產生可診斷的 log，後者談怎麼讀。
• Linux 除錯與診斷——本系列裝好、連入之後的下游；出問題時的判讀紀律與情境分流。
• Linux 工具選單——安裝與除錯要用的工具（CLI / 圖形桌面 / 遠端）有哪些選擇、推薦用哪些。
• Infra 心智模型：拿到雲端帳號的第一天——雲端主機的機器初始化是本系列的上游情境；被指派 infra 工作、拿到一台雲端主機後，先過本系列的 OS 連入與 bootstrap 前置，再進 infra 的資源管理。

成為 root：su -

su - 讓你從一般使用者切換成 root（系統管理員），整個 session 都以 root 身分操作。這個系列用到它，是因為在還沒有 sudo 的最小系統上，要裝 sudo、改系統設定，得先成為 root——而成為 root 的方式就是 su -，輸入 root 密碼後進入 root 的 shell。

那個 - 決定你載入哪一套環境。su - 啟動一個 login shell（模擬從頭登入、會跑完整的登入環境初始化），載入 root 自己的完整環境——把 PATH（shell 搜尋指令的目錄清單）換成 root 的（會包含 /usr/sbin 這類放管理工具的目錄）、工作目錄切到 root 的家。su（不加 -）則不啟動 login shell，環境多半沿用你呼叫時的、可能少掉那些管理工具目錄，於是有些管理指令會因為不在 PATH 裡而「找不到」，明明你已經是 root。所以要做系統管理，習慣用 su -。

su - 跟 sudo 解決的是不同情境。sudo 是「以 root 身分跑單一一條指令」，跑完就回到你自己；su - 是「整段都當 root」。這個系列先用 su - 是因為 sudo 還沒裝——一旦 sudo 裝好、wheel 群組（慣例上被授權可用 sudo 的群組）的授權設好，後面就改用 sudo <指令>，不再整段切 root。做完 root 的事，打 exit 回到原本的使用者。

用 nano 改設定檔

nano 是一個對照 vi 更直覺的文字編輯器，安裝過程改 locale.gen、hostname、sudoers 這些設定檔時會用到它。它的好處是所有快捷鍵都列在畫面最下面兩行，不必背。

那兩行裡的 ^ 符號代表 Ctrl 鍵。^O 就是 Ctrl+O、^X 就是 Ctrl+X。這個系列用到的幾個：

把這幾個串起來就是一次典型的設定檔編輯。以這個系列裡「解開 locale.gen 某一行的註解」為例：按 Ctrl+W 搜 en_US.UTF-8 UTF-8 跳到那行、用 Backspace 刪掉行首的 #、按 Ctrl+O 再 Enter 存檔、按 Ctrl+X 離開。改 hostname 則是 Ctrl+K 剪掉預設那行、打上新主機名、Ctrl+O、Ctrl+X。Ctrl+K 加 Ctrl+U 合起來就是「剪下再貼上」，是搬移整行的常見組合。

檔名與指令的大小寫

Linux 把大小寫當成不同的字元，這對檔名跟指令都成立。Setup 跟 setup 是兩個不同的東西、Documents 跟 documents 是兩個不同的資料夾、打 Sudo 不會執行到 sudo。這條規則貫穿整個系列：執行 archboot 的安裝程式是 setup（全小寫），啟動 Hyprland 桌面的指令是 Hyprland（首字母大寫），兩者差一個字母的大小寫就是不同的目標。

這對從 macOS 或 Windows 過來的人尤其常見，因為那兩個系統的預設檔案系統不分大小寫——在 Mac 上 File.txt 跟 file.txt 指向同一個檔，到了 Linux 就是兩個檔。同一個專案在 Mac 上跑得好好的，搬到 Linux 卻出現「檔案找不到」，常常就是某處大小寫對不上、而 Mac 的不分大小寫把問題藏了起來。

判讀方式很簡單：在 Linux 上，指令、檔名、路徑一律照原樣的大小寫打。錯誤訊息 command not found 或 No such file or directory 在你確定東西明明就在時，先懷疑大小寫。

shell 的幾個符號

這個系列的指令裡出現了幾個 shell 符號，它們是 shell 本身的語法、不是某個程式的參數，認得它們才讀得懂那些指令在做什麼。

> 跟 >> 是重導向，把本來會印到畫面的輸出改寫進檔案。> 覆蓋、>> 追加。系列裡 echo '%wheel ALL=(ALL:ALL) ALL' > /etc/sudoers.d/10-wheel 就是把那行文字寫進一個新檔，而設 authorized_keys 時用 >> 是為了追加、不洗掉既有的 key。

|（管線）把左邊指令的輸出，直接餵給右邊指令當輸入。傳 dotfile 進 VM 的 tar czf - . | ssh host 'tar xzf -' 就是把 tar 打包的資料流，不落地直接透過 ssh 送到對面解開。

&& 串接兩條指令，而且只有左邊成功才跑右邊。cd ~/dotfiles && ./scripts/install.sh 的意思是「先切到目錄，切成功了才跑腳本」——如果目錄不存在、cd 失敗，後面的腳本就不會在錯的目錄下執行。

$(...) 是命令替換，把括號裡指令的輸出，當成值填進當下這條指令。chsh -s "$(command -v zsh)" 會先跑 command -v zsh 得到 /usr/bin/zsh，再把這個路徑填給 chsh。理解這個語法，也才看得懂 工具驗證篇 講的 which 地雷：當 which 不存在、$(which zsh) 算出空字串，整條指令就拿到一個空值。

跟重導向相關的還有一個經典陷阱：sudo echo '內容' > /etc/某個-root-檔 會失敗。原因是重導向 > 由你的 shell 以你的身分執行，不是被 sudo 提權的那條指令——被提權的只有 echo，真正寫檔的還是你，而你沒權限寫那個 root 檔。解法是 echo '內容' | sudo tee /etc/某個-root-檔：tee 把流進它的 stdin 寫進檔案，而 tee 才是被 sudo 提權的那支，所以寫得進去。這個系列補 sudoers 檔時用的就是這個寫法。

權限對某些檔是硬要求，所以系列裡出現了 chmod。chmod 改檔案權限，那串數字是八進位的權限碼，三位分別代表擁有者/群組/其他人；每一位是讀（4）+ 寫（2）+ 執行（1）的和，所以 7 是全權、6 是可讀寫、4 是只讀、0 是無權。系列裡的 chmod 440（擁有者與群組可讀、其他人無權，給 sudoers 檔）、chmod 600（只有擁有者可讀寫，給私鑰）、chmod 700（只有擁有者全權，給 .ssh 目錄）就是這樣算出來的。這些檔對權限有要求——sudoers 必須是 440、私鑰必須只有自己讀得到，否則對應的工具會拒絕使用它們，所以那幾個 chmod 不是裝飾、是讓 sudo 跟 ssh 願意接受那些檔的條件。

下一步

認得這些基礎操作之後，就可以從 安裝選項判讀 開始走完整的安裝流程，過程中再遇到這幾個操作就不會卡。

本文用「桌面環境」泛指使用者看到的圖形介面整體。技術上，Hyprland 是 Wayland compositor——負責視窗合成和輸入管理，不含完整桌面環境（DE）的套件管理、設定面板等元件。GNOME、KDE Plasma 才是完整的 DE。但在故障隔離的討論中，關鍵區分是 kernel space vs userspace，compositor 和 DE 都在 userspace 這一側。

Kernel 與 Userspace 的隔離邊界

作業系統分成兩個執行空間。Kernel space 負責硬體驅動、記憶體管理、process 排程這些基礎設施。Userspace 跑所有應用程式，包括桌面環境本身。

兩個空間之間有硬體層級的隔離——CPU 的保護環機制（ring 0 是核心層級、ring 3 是應用程式層級，硬體強制限制 ring 3 的程式碼存取 ring 0 的記憶體）。Userspace 的 process 不管怎麼崩潰，都不會直接影響 kernel。Kernel 會清理掉崩潰的 process、回收它佔用的記憶體，然後繼續運作。

這個隔離機制解釋了一個關鍵差異：為什麼 Linux 上一個 app crash 通常只是那個視窗消失，而不會拖垮整台機器。

為什麼 Windows 會藍屏

Windows 的藍屏（Blue Screen of Death, BSOD）是 kernel panic 的表現——作業系統核心本身遇到無法恢復的錯誤，只能停機。

Windows 藍屏頻率較高的結構性原因在於顯示驅動的執行位置。Windows 把 GPU 驅動放在 kernel mode（WDDM 架構），NVIDIA 或 AMD 的驅動程式碼直接跑在核心空間。驅動有 bug 時，錯誤發生在 kernel space，清理掉再繼續的選項不存在——繼續執行可能造成資料損壞，只能停機。

藍屏頻率高是架構選擇的代價。把驅動放在 kernel mode 可以減少 context switch 的效能開銷，GPU 效能更好。代價是驅動 bug 的爆炸半徑從「app crash」升級成「整台停機」。Windows 10/11 已加入 TDR（Timeout Detection and Recovery）機制——GPU driver hang 時系統嘗試 reset driver 而非直接藍屏，大幅降低了 GPU 導致的 BSOD 頻率。但架構上 driver 仍在 kernel mode，藍屏的可能性仍然存在。

Linux 桌面的架構差異

Linux 桌面環境的顯示合成器（Hyprland、Sway、KDE Plasma 的 KWin）跑在 userspace。它們透過 DRM/KMS（Direct Rendering Manager / Kernel Mode Setting，Linux 的顯示子系統介面）跟 kernel 的 GPU 驅動溝通，但合成器本身的程式碼不在 kernel space 裡。

這個架構選擇的效果：

Compositor crash。Hyprland 如果遇到 segfault 或其他 fatal error，kernel 終止這個 userspace process。所有由它管理的視窗消失，螢幕回到 TTY 登入畫面或黑屏。但 kernel 還在跑——其他 TTY 可以登入，SSH 可以連線，背景的 service 繼續運作。

GPU driver bug。Linux 的 GPU 驅動分兩層：kernel module（可動態載入的核心擴充模組，如 nvidia.ko、amdgpu.ko）負責硬體操作，userspace 的 Mesa / NVIDIA userspace driver 負責 OpenGL/Vulkan 實作。Kernel module 出問題理論上可以 kernel panic，但實際行為取決於驅動。AMD 的開源 amdgpu 通常會嘗試 reset GPU 而非直接 panic，常見的表現是畫面凍結幾秒後恢復。NVIDIA 的閉源 nvidia.ko 是隔離模型的主要例外——kernel 社群無法審查或修復其程式碼，hang 時恢復能力遠弱於 amdgpu，經常拖垮整個 session 且 TTY 切換也受影響。這是後續故障場景中 NVIDIA 相關 caveat 的根源。

應用程式 crash。Firefox、VS Code、任何 GUI 程式崩潰，只有那個視窗消失。Compositor 繼續管理剩下的視窗，桌面環境不受影響。

TTY：kernel 存活時的首選救生通道

TTY（TeleTYpewriter）是 Linux 核心直接提供的純文字終端機介面，獨立於任何桌面環境。systemd 預設配置下有 6 個 virtual console（TTY1-TTY6）。Wayland compositor（如 Hyprland）通常佔用 TTY1，其餘可用。

切換方式：Ctrl+Alt+F2（切到 TTY2）到 Ctrl+Alt+F6（切到 TTY6）。

TTY 的重要性在於它不依賴 compositor。Hyprland 掛了、compositor crash 導致桌面消失——只要 kernel 還活著、GPU driver 仍能處理 VT switch，TTY 就能切過去登入操作：

• 用 htop 或 ps 查看哪個 process 出問題
• kill 有問題的 process
• 用 vim 或 nano 修改配置檔
• 重新啟動 Hyprland（Hyprland 指令）
• 如果需要，正常 reboot

TTY 切換失效的情境有兩種：kernel panic（極罕見）和 GPU 完全 hang 導致 VT switch 本身卡住（NVIDIA 閉源驅動在 Wayland 上較常見，需確保 nvidia_drm.modeset=1）。後者的替代手段是 SSH 遠端登入或 Magic SysRq 鍵（見常見故障場景的場景三）。

記憶體耗盡（OOM）的處理機制

Linux kernel 有 OOM Killer（Out of Memory Killer）機制——當記憶體和 swap 都用完、kernel 無法再分配新頁面時，自動挑選佔用記憶體最多、重要性最低的 process 強制終止，釋放記憶體讓系統繼續運作。

OOM Killer 的行為有時超出使用者的預期——它可能直接終止 Hyprland（因為 compositor 通常佔用不少記憶體），導致桌面突然消失。但關鍵是：系統沒有崩潰。Kernel 還在、TTY 還在、SSH 還在。

預防 OOM 的常見做法：

• 設定 swap（即使用 SSD，2-4GB 的 swap 也能在記憶體壓力大時提供緩衝）
• 啟用 systemd-oomd（userspace 的 OOM 管理，比 kernel OOM Killer 更早介入、更可控）
• 監控記憶體用量（btop 或 htop 可以看即時狀態）

故障層級速查

前五個層級都有恢復手段，只有 kernel panic 需要重開機。日常使用中遇到的故障多數落在前三層。

Caelestia 這類「desktop shell 專案」做的就是把上述元件統一設計、統一配色、統一出貨，省去自己一個個挑的功夫。它用的是 Quickshell（QML 框架）把所有元件包成一套風格一致的桌面。本模組教的是自己組裝的方式——理解各元件的配置，之後要用 Caelestia 或自己拼都能做。

Waybar：狀態列

Waybar 是 Hyprland 桌面最常用的狀態列。配置在 ~/.config/waybar/，分兩個檔案：config.jsonc（結構和模組）和 style.css（外觀）。

結構配置

 1// ~/.config/waybar/config.jsonc
 2{
 3    "layer": "top",
 4    "position": "top",
 5    "height": 36,
 6    "spacing": 4,
 7
 8    // 左中右三區塊各放哪些模組
 9    "modules-left": ["hyprland/workspaces", "hyprland/window"],
10    "modules-center": ["clock"],
11    "modules-right": ["pulseaudio", "network", "cpu", "memory", "battery", "tray"],
12
13    // 各模組設定
14    "hyprland/workspaces": {
15        "format": "{id}",
16        "on-click": "activate"
17    },
18    "clock": {
19        "format": "{:%H:%M}",
20        "format-alt": "{:%Y-%m-%d %H:%M}",
21        "tooltip-format": "<tt>{calendar}</tt>"
22    },
23    "battery": {
24        "format": "{capacity}% {icon}",
25        "format-icons": ["", "", "", "", ""],
26        "states": {
27            "warning": 30,
28            "critical": 15
29        }
30    },
31    "network": {
32        "format-wifi": "{essid} ({signalStrength}%)",
33        "format-ethernet": "{ifname}",
34        "format-disconnected": "Disconnected"
35    },
36    "pulseaudio": {
37        "format": "{volume}%",
38        "on-click": "pavucontrol"
39    }
40}

format 欄位裡的 icon 字元來自 Nerd Font——終端機與編輯器提到的字型安裝是這裡正常顯示的前提。

外觀 CSS

 1/* ~/.config/waybar/style.css */
 2
 3* {
 4    font-family: "MesloLGS Nerd Font", monospace;
 5    font-size: 13px;
 6}
 7
 8window#waybar {
 9    background-color: rgba(30, 30, 46, 0.85);
10    color: #cdd6f4;
11}
12
13#workspaces button {
14    padding: 0 8px;
15    color: #6c7086;
16    border-radius: 6px;
17}
18
19#workspaces button.active {
20    color: #cdd6f4;
21    background: rgba(137, 180, 250, 0.2);
22}
23
24#clock, #battery, #network, #pulseaudio {
25    padding: 0 10px;
26}
27
28#battery.warning {
29    color: #f9e2af;
30}
31
32#battery.critical {
33    color: #f38ba8;
34}

CSS 裡的色碼（#cdd6f4、#89b4fa、#f38ba8）來自配色方案（這個範例用的是 Catppuccin Mocha）。統一使用同一套色碼是 rice 視覺協調的基礎。

Config 裡的字族名必須跟系統實際安裝的字族逐字相符。Nerd Font 的圖示落在專屬碼位範圍，只有對應的那支字帶這些 glyph——指定一個沒裝的字族名，文字排版引擎找不到 glyph 就會顯示豆腐方塊。確認實裝字族名的方式：

1fc-list | grep -i meslo
2# MesloLGSNerdFont-Regular.ttf: "MesloLGS Nerd Font":style=Regular

引號內的字串是 config 該填的字族名。

同一份 Waybar config 能同時服務筆電、桌機與 VM，靠的是模組對缺少硬體的自動退化：battery 在沒有電池的機器直接隱藏該模組、不報錯也不留空位；pulseaudio 在沒有音訊服務時顯示為空；network 顯示當下實際在用的介面。不必為不同機器維護多份 config——把可能用到的模組都列上，用不到的那台自己消失。

Wofi / Rofi：啟動器

啟動器是按快捷鍵彈出的搜尋框，用來啟動應用程式、執行指令、搜尋檔案。

Wofi（Wayland 原生）配置：

1# ~/.config/wofi/config
2show=drun
3width=600
4height=400
5prompt=Search...
6insensitive=true
7allow_markup=true

 1/* ~/.config/wofi/style.css */
 2window {
 3    background-color: #1e1e2e;
 4    border: 2px solid #89b4fa;
 5    border-radius: 12px;
 6}
 7
 8#input {
 9    background-color: #313244;
10    color: #cdd6f4;
11    border-radius: 8px;
12    margin: 10px;
13    padding: 8px 12px;
14}
15
16#entry:selected {
17    background-color: rgba(137, 180, 250, 0.2);
18}

Rofi（需要 wayland fork rofi-lbonn-wayland）功能更豐富——支援多種 mode（drun、window、ssh、自定義 script）、主題系統更完整。如果需要進階功能（例如 emoji picker、密碼管理器整合），Rofi 是更好的選擇。

Mako / Dunst：通知

Mako 是 Wayland 原生的通知 daemon，負責顯示通知——它監聽 D-Bus 的 org.freedesktop.Notifications 介面、把收到的通知畫出來。產生通知的是應用程式，透過 libnotify 送上 D-Bus。所以一套能用的通知鏈需要兩半：daemon（顯示）和 libnotify（產生與遞送）。缺了 libnotify，連命令列自測用的 notify-send 都沒有。套件清單要同時列 mako 和 libnotify。

配置簡潔：

 1# ~/.config/mako/config
 2font=MesloLGS Nerd Font 11
 3background-color=#1e1e2e
 4text-color=#cdd6f4
 5border-color=#89b4fa
 6border-radius=8
 7border-size=2
 8padding=12
 9default-timeout=5000
10max-visible=3
11
12[urgency=critical]
13border-color=#f38ba8
14default-timeout=0

通知的視覺風格（圓角、配色、字型）要跟 waybar 和啟動器一致，這是整體 rice 不散的關鍵。

Nerd Font 的字符集只含 Latin、圖示與 Powerline 符號，不含中日韓。任何 CJK 文字（通知內文、視窗標題）若系統沒有 CJK 字型可 fallback 會變豆腐方塊。修法是安裝 CJK fallback（如 noto-fonts-cjk），fontconfig 會自動補字、不需改各工具的 config。另外，中途補裝字型後已在跑的 daemon 需重啟才看得到——reload 類指令只重讀設定檔、不重建記憶體中的字型快照（原理見 字型的可用集合在 process 啟動時決定）。

Grim + Slurp：截圖

Grim 負責截圖、Slurp 負責框選區域，兩者搭配使用。截圖結果透過 wl-copy 送進剪貼簿時，需要明確指定 MIME 型別：

1# 全螢幕截圖到剪貼簿
2grim - | wl-copy --type image/png
3
4# 框選區域截圖到剪貼簿
5grim -g "$(slurp)" - | wl-copy --type image/png
6
7# 全螢幕截圖存檔
8grim ~/screenshot.png

wl-copy 不帶 --type 時會嘗試透過 xdg-utils（xdg-mime）推斷 stdin 的型別。最小安裝環境沒有 xdg-utils 的情況下，PNG bytes 會被誤標成 text/plain，貼進影像應用程式就拿不到圖。明確帶 --type image/png 讓行為不依賴環境是否安裝了 xdg-utils。確認剪貼簿內容型別：

1wl-paste --list-types
2# 應顯示 image/png

Hyprland keybind 範例：

1bind = , Print, exec, grim - | wl-copy --type image/png
2bind = SHIFT, Print, exec, grim -g "$(slurp)" - | wl-copy --type image/png

子分類

建議的路線

• 拿到一台新機器：安裝與機器初始化 → 裝好後用 Dotfile 管理 把環境一鍵還原。
• 系統出問題：除錯與診斷，從診斷心法建立判讀紀律再依症狀分流。
• 想升級工具流：工具選單，看你天天用的 CLI / 桌面 / 遠端工具有沒有更好的選擇。

內容來自一次完整的 Arch Linux / Hyprland VM 實測與除錯：SSH 連不上、終端機噴亂碼、虛擬機開不起來、鎖屏狀態判錯、服務歸屬搞混——每個卡關點都被記錄下來，蒸餾成可重用的判讀路由，不綁特定發行版。

從哪篇開始

先讀 診斷心法 建立判讀紀律（讀權威狀態、四步流程），再依症狀進對應情境。

文章

依症狀的讀法

• 連不上、開不了機：機器 SSH 連不到、或虛擬機開不起來 → 機器連不到或起不來。
• 終端機行為怪：SSH 斷線後終端機噴亂碼、遠端打字亂碼、要從 SSH 操控圖形桌面 → 遠端連線與終端機問題。
• 某個狀態判不準：程式活著沒、服務歸誰、鎖沒鎖、session 還在不在 → 程序、服務與狀態怎麼判。
• 不想手動盯服務死活：想讓 service 掛掉時主動推播、或擔心整台機器當掉沒人知道 → 服務掛了怎麼自動知道。
• 想建立通用紀律：想要一套適用各種症狀的「不猜錯」判讀方法 → 診斷心法。

跟其他模組的交叉引用

• Linux 安裝與機器初始化——本系列的上游；把機器裝好、連入之後才輪到除錯。其中 可除錯的 bootstrap 談怎麼讓腳本產生可診斷的 log，與診斷心法的「讀程式自己的 log」一體兩面。
• Linux 工具選單——除錯要用的工具（CLI / 圖形桌面 / 遠端）有哪些選擇。
• 模組七：日誌判讀與診斷工具——桌面環境層的日誌判讀，與這裡的通用診斷紀律呼應。

這個系列講的不只是「有哪些桌面工具」，而是選它們時該看什麼：相依足跡、桌面環境耦合、功能相依（掛載 / 縮圖 / 網路這些側欄功能背後各是一個額外套件）。

文章

相關

• 純終端機下的檔案管理器（yazi / broot / ranger）是另一條路，見 CLI 環境工具 的檔案管理器段。
• 桌面環境本身（GNOME / KDE / Hyprland）怎麼選、各自的擴充生態，見 桌面環境選型；選了 Hyprland 之後怎麼組裝，見 Dotfile 管理：桌面 Rice 設計。
• 在圖形桌面上安裝這些工具前的環境與相依判讀，跟 除錯與診斷 的權威狀態紀律同源。

SSH「連不上」本身（Permission denied、Host key verification failed、Connection refused）的判讀與修復，見 外部連入與無 key 的 bootstrap 路徑 的重連段落。這篇處理的是「連上了、但終端機或 session 的狀態不對」的那些情況。

SSH 斷線後本機終端機噴亂碼、狂跳字元

一個嚇人但無害的情況：SSH 連線被中斷後，你本機的終端機開始瘋狂輸出像 <35;80;24M 這樣的序列，尤其在你移動滑鼠時狂跳。這不是遠端機器在打字，是你本機的終端機被卡在滑鼠回報模式。

判讀關鍵在「什麼時候噴」：如果那串亂碼只在你移動滑鼠時出現、而且形如 數字;數字M，那就是滑鼠座標回報。成因是遠端跑的某個全螢幕程式（TUI、編輯器、終端機多工器）啟動時對終端機開了滑鼠追蹤模式，SSH 被硬斷時它來不及送出「關閉滑鼠模式」的序列就死了，於是你本機終端機還停在回報模式，滑鼠一動就把游標座標當輸入送進來。

修復是重置終端機的模式，跟遠端機器無關：

• 最快：開一個新的終端機分頁 / 視窗。模式是「那個終端機 session」的狀態，新視窗是乾淨的。
• 救現有視窗：先把滑鼠移開別動（洪流會停），盲打 reset 再 Enter，送出終端機重置。
• 若 reset 沒清掉，補送關閉滑鼠回報的序列：printf '\033[?1000l\033[?1002l\033[?1003l\033[?1006l'。

同一類的還有「alternate screen 沒還原」——遠端的全螢幕程式異常結束時，本機終端機可能卡在替代畫面緩衝區，看起來像畫面清空或凍結。reset 同樣能救。歸納起來：SSH 被硬斷後本機終端機行為異常，先懷疑「對端程式來不及還原終端機模式」，用 reset 或開新視窗處理本機終端機狀態，不必急著重連遠端。

遠端打字變亂碼、重複、位置錯亂

連上遠端後，如果互動式輸入變得不對——打一個字出現好幾個、游標位置錯亂、畫面重繪殘影——通常是兩層問題之一，判讀方式是分開排除。

第一層是字元編碼（locale）。從某些本機（例如 macOS）SSH 進 Linux 時，本機會把 LC_CTYPE 之類的變數帶過去；如果遠端沒有對應的 locale、就會退回 POSIX/C locale，讓終端機的行編輯（ZLE、readline）對多位元組字元的寬度判斷出錯，表現為輸入重複或錯位。判斷方式是在遠端 locale 看目前值、locale -a 看有沒有裝對應的 UTF-8 locale。修法是在遠端明確設好 LANG / LC_CTYPE 到一個實際存在的 UTF-8 locale，而不是讓它繼承一個遠端不認得的值。

第二層是終端機能力資料庫（terminfo）。你本機終端機的 TERM 值（例如某些新終端機用 xterm-ghostty 之類的自訂值）如果在遠端沒有對應的 terminfo 條目，遠端程式就不知道怎麼正確地清行、移動游標、重繪，畫面就會亂。判斷方式是在遠端 echo $TERM 看值、infocmp $TERM 看遠端認不認得。修法是把本機的 terminfo 條目送過去讓遠端安裝：infocmp -x $TERM | ssh <遠端> 'tic -x -'。

先分清是 locale 還是 terminfo，兩者症狀相似但修法不同：locale 是編碼寬度、terminfo 是繪製指令。查 locale 跟查 $TERM + infocmp 就能分開。

從 SSH 操控遠端的圖形桌面

想從一條純文字的 SSH 連線去操作遠端的 Wayland 圖形桌面（例如啟動應用、截圖、送 IPC 指令）時，會撞到兩類界線，判斷對是哪一類就知道怎麼繞。

第一類是圖形程式需要知道連到哪個顯示。SSH 進來的 shell 預設沒有圖形環境的環境變數，直接跑圖形程式會找不到 display。要對著遠端那個已經在跑的 Wayland session 操作，得補上它的環境變數：XDG_RUNTIME_DIR（通常 /run/user/<uid>）、WAYLAND_DISPLAY（socket 名，如 wayland-1）、必要時還有該 compositor 的 instance 變數與 DBUS_SESSION_BUS_ADDRESS。這些值怎麼撈：socket 名用 ls /run/user/$(id -u)/wayland-* 看；其餘變數直接從那個圖形 session 既有行程的環境複製最準——cat /proc/<compositor-pid>/environ | tr '\0' '\n' | grep -E 'WAYLAND_DISPLAY|XDG_RUNTIME_DIR|DBUS_SESSION|_INSTANCE_'（<compositor-pid> 用 pgrep -x Hyprland 之類找）。撈到後 export 進當前 SSH shell，這條連線就能對遠端的圖形 session 下指令、grim 截圖。

第二類是有些東西必須從實體圖形終端機（VT，即 Ctrl+Alt+F1~F6 切換的那些文字主控台）啟動，SSH 的 pty 起不來。Wayland 的合成器（compositor，畫桌面、把視窗合成到螢幕、管輸入輸出的核心程式，如 Hyprland）需要一個真正的圖形 VT 上的登入 session，拿到 DRM master（對顯示卡的獨佔繪圖控制權）與 logind seat（一組綁在一起的實體螢幕／鍵鼠裝置）才能啟動；從 SSH 的 pty 起它的預設 backend 會直接失敗（例如報 backend 建立失敗），因為預設 backend 要的 DRM master 與 seat 在 SSH 這條連線上不存在。判讀訊號：合成器一啟動就報 seat / DRM / backend 相關的錯，而你是從 SSH 起的——那就是這個界線。（例外：合成器多半有 headless backend，例如設 WLR_BACKENDS=headless 就不要 DRM master、不需 VT，專給 CI、雲端、自動化測試用；nested（跑在另一個 Wayland session 裡）也不需要。所以精確說是「預設 backend 需要圖形 VT」，不是「合成器一定起不來」。）

繞法是回到那台機器的實體圖形終端機去啟動 compositor，但「回到 VT」這件事也可以從 SSH 遠端做：

• sudo chvt <N> 從 SSH 切換那台機器目前顯示的虛擬終端機到第 N 個，比在虛擬機視窗裡跟宿主的 Ctrl+Alt+Fn 快捷鍵搏鬥穩定。
• 切過去卻是空白、沒有登入提示，通常是那個 VT 上沒有 getty 在跑：sudo systemctl start getty@tty<N>（開機時 enabled 但 inactive 是常見狀態，logind 的 autovt 沒觸發）。
• sudo fgconsole 確認目前是哪個 VT 在前景。

還有一個容易混淆的點：一台虛擬機可能同時有「序列主控台」跟「圖形顯示」兩個獨立輸出。在 guest 內 chvt 只切圖形那側，序列主控台看到的畫面不會變。如果你在虛擬機軟體裡看的是序列主控台，圖形桌面得切到顯示輸出那個 view 才看得到。判讀：切了 VT 但畫面沒反應，先確認你正在看的是哪個輸出。

判讀路由

遠端 / 終端機問題的分流：

• 本機終端機噴亂碼、只在動滑鼠時噴 → 滑鼠回報模式沒關（本機終端機狀態），reset 或開新視窗。
• 遠端打字重複 / 錯位 → 分 locale（查 locale）與 terminfo（查 $TERM + infocmp）。
• 圖形程式在 SSH 下找不到 display → 補 WAYLAND_DISPLAY / XDG_RUNTIME_DIR 等環境變數。
• compositor 從 SSH 起不來、報 seat/DRM 錯 → 它需要實體 VT，用 chvt + getty@tty<N> 回到圖形 VT 啟動。
• SSH 連不上（拒絕 / host key / refused）→ 見 外部連入與無 key 的 bootstrap 路徑。

這幾種分流的共同底線是先讀權威狀態（locale、$TERM、runtime 目錄、loginctl、fgconsole）再下判斷；背後的方法論見 診斷心法。

這篇給每個關鍵選項一條判斷軸，而不是一份「照著點」的步驟。底下用一次具體的安裝當作貫穿例子：在 Apple Silicon 的 UTM 上用 archboot ISO 裝 Arch Linux ARM，目標是一台演練 dotfile 部署的測試 VM。例子是具體的，但判斷軸跨發行版通用——locale、分割、bootloader 這些抉擇在多數 Linux 安裝程式裡都會以類似形式出現。

怎麼建立 VM、燒錄並開機到安裝程式，是跟環境綁定的前置——UTM、VirtualBox、實體機各不相同——不在這條判讀軸的範圍；這篇從「安裝程式已經跑起來、開始問你選項」接手，給的是每個選項的判斷軸，不逐頁帶某個安裝程式的選單怎麼點。底下的指令與選單名稱以 archboot / Arch 呈現，換 Ubuntu（Subiquity 安裝程式）或 Fedora 時，選項的判斷軸一樣成立，但選單長相、套件組名稱、指令會不同。

系統語系與時間

系統語系決定的是錯誤訊息、log、系統工具輸出用哪種語言，不是你日常打字的語言。這兩件事容易混為一談。日常輸入中文是桌面層的字型與輸入法問題，跟系統 locale 無關；系統 locale 影響的是當某個服務崩潰、你在 journalctl 裡讀它吐出來的那行訊息時，那行字是英文還是被翻譯過。

把系統 locale 留在 en_US.UTF-8 的理由是可搜尋性。當你把一段錯誤訊息貼到搜尋引擎或問別人，英文訊息能對上絕大多數的文件、issue、Stack Overflow 答案；翻譯過的訊息往往一個結果都搜不到。這條判斷軸對伺服器、開發機、任何你預期會除錯的機器都成立。會選非英文 locale 的情境通常是給終端使用者的桌面，且該使用者不除錯——那是另一種機器。

時區的選擇影響 log 的時間戳跟排程任務的觸發時刻，挑你所在地即可。另一個相關的決策是「硬體時鐘存 UTC 還是本地時間」：選 UTC。Linux 慣例是硬體時鐘存 UTC、顯示時再換算成時區，這樣跨時區搬機器、或 NTP 校時都不會錯亂。會需要存本地時間的唯一常見情境是跟 Windows 雙開——Windows 預設把硬體時鐘當本地時間——而 VM 或純 Linux 機器沒有這個包袱。

網路

安裝階段的網路設定要回答兩個層次：當下能不能連、以及這份設定會不會帶進裝好的系統。第一層通常很直覺——選到對的網卡、用 DHCP 讓它自動拿 IP。虛擬機的 NAT 網路會自動發 IP，所以選 DHCP、不要手動設 static，省去算網段的麻煩。

第二層是真正會咬人的地方：安裝程式裡設好的網路，不保證會出現在重開機後的系統裡。這是 VM 裝 Linux 常見的斷網點——安裝時明明能上網裝套件，重開機後卻連不出去，因為安裝環境的網路設定沒被複製到目標系統。判讀方式是裝好首次開機後立刻驗證：看網卡有沒有拿到 IP、能不能解析一個域名。

1ip -brief a          # 網卡有沒有 IP、狀態是不是 UP
2ping -c 3 archlinux.org   # 解析成功就證明對外連線 + DNS 都通

DNS 能把域名解析成 IP，本身就證明對外連線是通的（DNS 查詢就是一次網路往返），所以這條 ping 即使對方不回 ICMP 也已經給了答案。在前述的 archboot 例子裡，網路設定確實有被複製進目標系統並由 systemd-networkd 接手，重開機後免再手動設——但這是該安裝程式的行為，不能假設每個安裝程式都這樣。把「首次開機驗網路」當成固定動作，比預設它一定會通安全。

套件鏡像

鏡像源決定你從哪裡下載套件，挑地理上接近的那個。基礎系統加上一套桌面動輒上 GB，選對岸的鏡像跟選同城的鏡像，下載時間差好幾倍。安裝程式給的鏡像清單通常按國家排，往下捲找你所在地區的；找不到完全同國的，就退而求其次選同區域、且穩定的大型鏡像。

這個選擇的另一個作用是順帶確認你裝的是哪個發行版分支。前述例子的鏡像清單全是 archlinuxarm.org，這證實了 archboot 的 aarch64 ISO 裝出來的是 Arch Linux ARM（ARM 移植版），而不是 x86 的 Arch——同一條安裝路徑產出的是哪個分支，鏡像來源會洩漏給你看。

磁碟分割

磁碟分割是整個安裝裡選項最多、也最不可逆的一段，但判斷軸只有一條：這台機器需不需要在分區層面做隔離。需要隔離的情境——多系統共存、加密、資料與系統分離以便重灌不丟資料——每多一個，分割就多一層結構。不需要的情境，多切一刀都只是增加「一邊爆一邊空」的風險。下面逐項拆解，但它們服務的是同一個判斷。

自動分割 vs 手動分割

自動分割（清空整碟、安裝程式幫你建標準佈局）適用於整碟專屬、沒有要保留任何既有資料的機器。測試 VM 的磁碟是全新的、整碟給這個系統用，自動分割沒有任何代價，還省去手動算 EFI 大小、root 大小、對齊、格式化、掛載這一連串容易錯的步驟。

手動分割的價值在你需要非標準佈局時才浮現：多系統共用某個分區、要留一塊不格式化的資料區、要套 LVM 或 LUKS。這些是真實主力機與伺服器會遇到的需求，但對一台「目標是驗證 dotfile 部署」的 VM 是純雜訊——它們屬於另一個主題，不該混進這次的安裝。判讀訊號很簡單：你說得出一個具體的隔離需求，才手動分割；說不出來，自動分割就是對的。

分區識別方式（PARTUUID）

分區識別方式決定 fstab（開機時決定哪個分區掛到哪的設定檔）跟 bootloader 怎麼指涉每個分區，在 GPT（現代 UEFI 機器的分區表格式）磁碟上選 PARTUUID。這個選擇的後果是「重開機後系統找不找得到自己的分區」。PARTUUID 綁在分區本身、跨重開機穩定，而且重新格式化檔案系統也不會變；相對地，檔案系統層級的 UUID 一重格就變，會讓 fstab 失效，而 /dev/vda1 那種 kernel 名稱會隨偵測順序浮動，最不穩。穩定性的排序是 PARTUUID 優於 FSUUID 優於 kernel 名稱，GPT 磁碟用最穩的那個（這三種識別方式的細節見 分區識別卡）。

EFI 分區的掛載點與大小

EFI 系統分區（ESP）放開機載入器與 kernel，掛載點的選擇取決於這台機器是不是單一作業系統。把 ESP 掛在 /boot（單系統佈局）讓 kernel 跟開機檔住在同一個分區、維護最單純；把 ESP 掛在 /efi、kernel 另放（多系統佈局）是為了多個 OS 共用同一個 ESP 才需要的結構。單系統的機器選多系統佈局，只是憑空多一層目錄。

ESP 大小在單系統佈局下要算進 kernel 與 initramfs（開機初期把真正的 root 掛起來之前、用來載入驅動的小型臨時根檔系統）。一個 kernel 加上它的 initramfs（含 fallback）大約一兩百 MB，再加上 FAT32 ESP 約 260 MiB 的實務下限，512 MiB 是在下限之上留餘裕。會需要更大的情境是你要同時保留多個 kernel 版本——但單 kernel 的 VM 用不到，給太大只是浪費。

Swap

Swap 是記憶體不足時的安全墊，大小取決於這台機器的記憶體壓力型態，不是一個固定公式。對一台只有 4 GB RAM、且要在上面從原始碼編譯套件的 VM，編譯瞬間的記憶體尖峰很容易把實體記憶體吃爆、觸發 OOM 把進程殺掉。給 2 GB swap 當緩衝，擋住這種尖峰、避免安裝跑到一半被中斷。

swap 分區的磁碟成本不是一次付清的。mkswap 只寫一個 header，實際沒被換出的頁不會佔用宿主磁碟空間（在稀疏配置的虛擬磁碟上尤其明顯），用到才寫。所以「為了保險多給一點 swap」的代價，比直覺以為的小。判讀軸是看工作負載：會編譯、會跑吃記憶體的服務、RAM 又緊，就給足 swap；純文書、RAM 寬裕，小一點或不給都行。

swap 還有形態的選擇，這裡用分區 swap 是因為在安裝程式階段一併切好最省事，不代表它比另兩種好。swapfile（一個檔案，事後可隨時調大小或移除）避開了「分割最不可逆」的痛點；zram（壓縮記憶體 swap，不碰磁碟）對低 RAM 加編譯尖峰正是設計情境，現代發行版很多預設用它。換句話說，2 GB 這個量是看編譯尖峰定的，而「切成分區」只是配合安裝當下一次到位——若你跳過安裝期的 swap、事後用 swapfile 或 zram 補，是等價的可逆路徑。

檔案系統

檔案系統的選擇是在「簡單可靠」與「進階功能」之間取捨，預設往簡單那邊靠。ext4 簡單、穩、在各平台行為一致、修復工具成熟，對一台只要求「可靠地存取檔案」的機器是零驚喜的選擇。btrfs 提供快照、subvolume、透明壓縮，但代價是要規劃 subvolume 佈局、還要理解它寫時複製（CoW）的一些行為差異；這些功能在你會用快照回滾的主力機上很有價值，在演練 VM 上是雜訊。xfs 同樣穩定，但對這類用途相對 ext4 沒有決定性優勢。更特定的 zfs、f2fs 不在一般 VM 的考慮範圍——zfs 在 Arch / ARM 上是非主線 kernel 的 out-of-tree 模組、授權與維護成本高，f2fs 是為快閃裝置設計、VM 用不到。

判讀軸是你會不會用到進階功能。會固定用快照回滾系統狀態——選 btrfs 並接受它的佈局複雜度；只是要一個可靠的檔案系統——ext4。快照這類能力跟下面的獨立 /home 一樣，是真實機器的儲存規劃主題，值得另外深入，但別為了「聽起來比較強」就把它的複雜度帶進一台用完即丟的機器。

獨立 /home vs 單一 root

獨立 /home 分區的價值是「重灌系統不丟個人資料」，這是主力機的需求，不是每台機器都需要。把 /home 切成獨立分區，重裝系統時可以只格式化 root、保留 /home 裡的設定與檔案。一台用完即丟的演練 VM 沒有這個需求——它的整個生命週期就是裝起來、驗證、丟掉。如果你想跨多次實驗保留狀態，VM 情境更貼切的手段是宿主層的快照或共享資料夾，而不是在 guest 裡切獨立 /home——後者解決的是「重灌 OS 保資料」，不是「保留實驗狀態」。

把空間切兩半的隱性代價是失衡風險。假設總共十幾 GB，照預設切一塊給 /、剩下給 /home，所有系統套件（桌面全套依賴都裝在 /usr、算 /）擠在前者、容易先滿，而 /home 那邊空著——典型的一邊爆一邊空。把全部空間當一個池子用的單一 root 佈局，不會人為卡死任一邊，對不需要「重灌保資料」的機器最不容易出事。

Bootloader

開機載入器決定韌體怎麼找到並載入 kernel，在虛擬機上選 GRUB 而非直接用 EFISTUB，理由是可靠性（韌體到 kernel 的整條交棒過程見 UEFI 開機鏈卡）。EFISTUB 讓 UEFI 韌體直接載入 kernel、不經過獨立的 bootloader，最精簡，但它完全依賴寫進 UEFI NVRAM（韌體用來存開機項的非揮發記憶體）的開機項。問題在於 QEMU 系的虛擬機（UTM 底層即是）對 EFI 變數的儲存有時不穩，一旦 NVRAM 裡的開機項掉了，韌體就找不到 kernel、機器開不了——這在 VM 環境是會實際踩到的坑。

GRUB 的容錯來自它（以 removable 模式安裝時）多寫了一份。除了 NVRAM 開機項，grub-install --removable 會在 ESP 的標準 fallback 路徑（aarch64 是 \EFI\BOOT\BOOTAA64.EFI）也放一份，就算 NVRAM 開機項丟了，韌體仍會從 fallback 路徑找到 GRUB；VM 環境的安裝程式通常以這個模式裝 GRUB，正是看上這層保險。它還附帶一個開機選單，當 kernel 或 initramfs 出問題時，可以進選單救援、加開機參數除錯——演練時的容錯空間大很多。

判讀軸是環境的 NVRAM 可靠度。在 NVRAM 穩定的實體機上，EFISTUB 的極簡是漂亮的選擇；在 NVRAM 可能不穩的 VM 上，可靠性優先，GRUB 的「多寫一份 fallback + 救援選單」更穩妥。GRUB 不是唯一的可靠選擇——systemd-boot 同樣是有開機選單、能裝到 fallback 路徑的獨立 bootloader，又比 GRUB 輕，在 VM / 單系統同樣站得住；這裡落在 GRUB 是因為 archboot 安裝程式預設以 removable 模式裝它，不是 GRUB 獨佔可靠性。GRUB 自己的設定檔在 VM 上用預設值即可，不需要額外的 kernel 參數。

下一步

選項選完、系統裝好、重開機進得去之後，先別急著開始用——「裝好了」跟「能用了」之間往往還缺一截：這台最小系統不一定有你需要的基本工具。最小安裝後的工具驗證與補足 就是在補那一截。

從安裝到桌面就緒的完整依賴順序，見 模組零的操作順序指引；本篇是它「安裝作業系統」那一步的展開。

這篇用「圖形檔案管理員」當具體案例，但判讀方式適用於任何你想加進最小環境的桌面 app：先看它的相依樹拖進什麼，再決定值不值得。

三種實作的實測相依

同樣是「有側欄、有選單、能瀏覽掛載裝置」的圖形檔案管理員，三個主流實作在一台已有 GTK3 的 Arch ARM 機器上，各自會新裝的套件數量如下（pacman -S --needed --print 實測）：

差異的來源不是「檔案管理員本身多大」，Thunar 跟 Nemo 的主程式都在 7–10 MB 量級。差的是後面那條相依鏈。

Thunar 與 PCManFM-Qt：桌面無關的獨立程式

Thunar 與 PCManFM-Qt 都是刻意做成「不依賴完整桌面環境」的檔案管理員。Thunar 雖然出身 XFCE，但它拖進的 8 個套件是 XFCE 的基礎函式庫（設定系統 xfconf、工具庫 libxfce4util、UI 庫 libxfce4ui），不是 XFCE 桌面本身——你不會因此裝到 XFCE 的面板、視窗管理器或 session。PCManFM-Qt 走 Qt 棧，帶的 layer-shell-qt 反而是 Wayland 原生整合的加分項。這兩個裝下去，機器還是那台只有 Hyprland 的機器，只是多了一個能開的檔案管理員。

Nemo：為 Cinnamon 而生，假設 Cinnamon 在旁邊

Nemo 是 Cinnamon 桌面的檔案管理員，它的相依反映了這個出身：cinnamon-desktop 提供背景與顯示設定的整合、xapp 是 Cinnamon 系列跨桌面的整合層。即使你只想要「開一個視窗看檔案」，這些桌面元件也會一起裝上，因為 Nemo 在程式碼層面就假設它們存在。這不是 Nemo 寫得差，是它本來就不是設計給「裸 window manager」用的——它預期自己跑在 Cinnamon session 裡。

Nemo 那 36 個套件裡，還有一大塊來自它把 gvfs 列成硬相依（下一節說明 gvfs 是什麼），而 gvfs 又拖進整套磁碟管理棧（udisks2、libblockdev 的 8 個子模組、mdadm、parted、volume_key）。所以 Nemo 的相依樹是「Cinnamon 桌面元件」加「完整磁碟/檔案系統管理」兩層疊起來的結果。

gvfs：側欄那些功能不是檔案管理員自己做的

截圖裡檔案管理員側欄常見的「Devices（掛載裝置）」「Network（瀏覽網路芳鄰）」「Trash（垃圾桶）」，多半不是檔案管理員自己實作的，是 gvfs（GNOME Virtual File System） 這個後端提供的。gvfs 用一層虛擬檔案系統把「掛載 USB 隨身碟」「連 SMB 網路分享」「把檔案丟垃圾桶」這些操作抽象成統一介面，讓檔案管理員不必自己處理每一種裝置與協定。

這帶出一個重要判讀：輕量不是免費的，當功能對等時，相依會靠攏。 Thunar 與 PCManFM-Qt 把 gvfs 列成 optional dependency——不裝也能開檔案管理員，但側欄就沒有掛載、垃圾桶、網路那些功能。要讓輕量檔案管理員有截圖裡那種完整側欄，你得自己補 gvfs，而補上 gvfs 就會連帶拖進它的相依（udisks2、polkit、fuse3、libsecret 等）。Nemo 把 gvfs 設成硬相依，只是把這個選擇替你做了。

所以公平的比較不是「Thunar 8 個 vs Nemo 36 個」，而是「Thunar + gvfs + 縮圖 vs Nemo」。補齊功能後，Thunar 這條路線仍然省下的是 Nemo 獨有的那層——cinnamon-desktop、xapp、xapp-symbolic-icons 這些桌面環境耦合元件。那層，才是「為了一個檔案管理員裝半個 Cinnamon」真正可以省掉的部分。

tumbler：縮圖也是一個額外套件

檔案管理員顯示圖片/影片縮圖，同樣不是內建的，靠的是縮圖服務。Thunar 家族用 tumbler，影片縮圖再另外需要 ffmpegthumbnailer。這是「一個功能對應一個額外套件」的又一個例子——最小環境裡，縮圖、掛載、網路瀏覽每一項都是你明確選擇要不要付相依成本的功能，而不是預設就有。

Wayland / Hyprland 下的注意事項

這些檔案管理員多數是 X11 時代的 GTK/Qt 程式，在 Wayland 下會透過 XWayland 或原生 Wayland 後端執行。PCManFM-Qt 帶的 layer-shell-qt 是 Wayland 的 layer-shell 整合；GTK 的 Thunar/Nemo 在 Wayland 下一般走 GTK 自己的 Wayland 後端。開啟/儲存檔案對話框、拖放、縮圖預覽在裸 Hyprland（沒有完整 portal 服務）下的實際行為，取決於有沒有裝 xdg-desktop-portal 與對應的後端。

[待實機驗證] 以下行為尚未在本系列的 Hyprland 實機環境確認，先標記待驗證：(1) Thunar 補上 gvfs 後，側欄的 Devices/Network/Trash 是否如預期出現並可用；(2) tumbler + ffmpegthumbnailer 的縮圖在 Wayland 下是否正常產生；(3) 三者在裸 Hyprland（無完整桌面 portal）下的檔案對話框與拖放行為；(4) Nemo 在沒有 Cinnamon session 的情況下，桌面圖示、設定整合等功能是否失效或報錯。這些是「相依裝了之後實際好不好用」的問題，相依數量本身（上表）已是實測確定值。

風險與注意事項

移除後的孤兒套件：裝了 Nemo 再反悔移除時，cinnamon-desktop、xapp 那一票被拖進來的相依會變成沒人依賴的孤兒（pacman -Qtd 可列出）。用 pacman -Rns nemo 移除時帶走遞迴相依，或定期清孤兒，否則那半個 Cinnamon 會留在系統裡。輕量檔案管理員因為拖進的東西少，這個問題也小。

桌面環境服務未跑的副作用：把為某個桌面環境寫的 app 裝進裸 window manager，它預期的那些服務不在時，部分功能可能靜默失效或在啟動時報錯。這類問題不會在相依解析階段出現——套件裝得起來，是執行時才發現某個整合功能沒作用。（Nemo 在無 Cinnamon 下的具體表現，見上方待驗證項。）

選型判準：最小化的 Hyprland 想要一個圖形檔案管理員，優先考慮桌面無關的 Thunar 或 PCManFM-Qt；需要截圖那種完整側欄功能時，明確補上 gvfs（掛載/垃圾桶/網路）與 tumbler（縮圖），把相依成本花在你真的要用的功能上。以 Thunar 為例，完整一套是 pacman -S thunar gvfs tumbler ffmpegthumbnailer（gvfs 給掛載/垃圾桶/網路、tumbler + ffmpegthumbnailer 給圖片與影片縮圖）。除非你本來就跑 Cinnamon，否則不建議為了單一檔案管理員把 Nemo 的整套桌面元件裝進來——那是付了桌面環境耦合的代價，卻沒用到那個桌面環境。

待實機驗證清單

這篇的相依數量與相依樹是實測確定的；以下「裝了之後實際體驗」的部分待在 Hyprland 實機補驗證：

• Thunar + gvfs + tumbler + ffmpegthumbnailer 的完整側欄與縮圖行為
• 三種檔案管理員在裸 Hyprland（XWayland vs 原生 Wayland、portal 有無）下的差異
• Nemo 脫離 Cinnamon session 的功能缺損範圍
• 加進 packages-arch.txt 後，bootstrap 一鍵安裝這條路線的實際落地結果

為什麼拿 Nemo 當「重」的代表

上表用 Nemo 當桌面環境耦合的代表，是因為它把耦合展示得最乾淨——cinnamon-desktop + xapp 那層桌面元件加上 gvfs 硬相依，剛好對照出 Thunar / PCManFM-Qt 省掉的是什麼。但它不是最重的：GNOME 的 Nautilus（nautilus）與 KDE 的 Dolphin（dolphin）是更 canonical 的「裝檔案管理員就拖進半個桌面」例子。Nautilus 深度綁 GNOME 的 GTK4 / libadwaita / tracker 索引棧，在非 GNOME 環境裝它會拉進一串 GNOME 平台庫；Dolphin 綁 KDE 的 Frameworks（KIO、Baloo 等），在非 KDE 環境同理。判讀方式跟 Nemo 一節相同：檔案管理員的相依樹反映它預期跑在哪個桌面裡。真要在裸 Hyprland 上驗，pacman -S --needed --print nautilus / dolphin 會列出各自那串平台庫——數量通常比 Nemo 更可觀（實測 Nautilus 72、Dolphin 91，約 Nemo 的 2 到 2.5 倍）。

零相依對照：純終端機檔案管理員

如果你在意的正是相依足跡，還有一條完全繞開圖形棧的路：終端機檔案管理員（yazi / lf / nnn / ranger）在終端機裡跑，不需要 GTK / Qt / gvfs / 桌面環境那一整套。yazi（Rust、內建預覽與非同步 I/O）與 lf、nnn（C、極小）在裸 Hyprland 或純 SSH 環境下都是近乎零額外相依的選擇——你已經有終端機，它們就能跑。代價是純鍵盤操作、沒有圖形檔案管理員那種拖放與縮圖牆。這是「圖形 vs 終端機」的取捨，不是同一條路上的輕重之分：要滑鼠拖放、縮圖預覽走圖形檔案管理員；要零相依、鍵盤流、SSH 下也能用走 TUI。TUI 檔案管理員的比較見 CLI 環境工具的檔案管理器 TUI。

下一步

• 這篇談的是「加桌面 app 時怎麼判讀相依成本」，套件清單本身怎麼設計、怎麼被 bootstrap 一鍵安裝，見 模組八：Bootstrap script 與套件清單。
• Hyprland 本體與配套工具的安裝，見 模組五：安裝與環境建置。
• 這台 Hyprland 是在 VM 上建起來測的，VM 能測什麼、什麼要留到實機，見 VM 環境設定與測試矩陣。

場景一：Hyprland compositor crash

症狀：所有視窗同時消失，螢幕變黑或回到 TTY 登入畫面。滑鼠鍵盤有反應（可以切 TTY），但沒有桌面。

原因：Compositor process 遇到 fatal error 被 kernel 終止。常見觸發條件包括 plugin 相容性問題、特定 Wayland 協議操作觸發的 bug、GPU driver 回傳異常狀態。

恢復步驟：

注意：以下步驟中 killall Hyprland 或重啟 Hyprland 會終止所有由 compositor 管理的視窗，未存檔的工作會遺失。如果可能，先透過 TTY 或 SSH 嘗試存檔（如 kill -USR1 <pid> 對支援的應用程式觸發存檔）。

1. Ctrl+Alt+F2 切到 TTY2
2. 用你的帳號登入
3. 檢查 Hyprland 的最後錯誤訊息：

1# 通用方式（不管 Hyprland 怎麼啟動都有效）
2journalctl -b | grep -i hypr | tail -30
3
4# 如果 Hyprland 是 systemd user unit，可以更精準地查：
5journalctl --user -u hyprland -n 50 --no-pager

4. 重新啟動 Hyprland：

1Hyprland

5. 如果反覆 crash，檢查最近改過的 config：

1cd ~/.config/hypr
2git diff  # 如果 dotfile 有版控

預防：config 改動後用 hyprctl reload 測試，不要直接重啟。啟用 plugin 前確認版本跟 Hyprland 版本相容。

場景二：單一桌面工具掛了

症狀：狀態列（waybar）消失、啟動器（wofi/rofi）叫不出來、通知（mako/dunst）不跳了。桌面其他功能正常，視窗可以操作。

原因：這些工具各自是獨立的 process。掛了只影響自己的功能，不影響 compositor 或其他工具。常見原因是 config 語法錯誤（改完 config 後觸發）、記憶體洩漏（長時間運作後）、或外部服務連線異常（如 waybar 的某個 module 連不到系統匯流排）。

恢復步驟：

判斷啟動方式：如果工具是在 Hyprland config 裡用 exec-once（Hyprland 的自動啟動指令，compositor 啟動時執行一次）啟動的，用 killall + 手動重啟；如果是 systemd user unit，用 systemctl --user。

exec-once 啟動方式（多數 Hyprland 安裝的預設做法）：

1# waybar 掛了
2killall waybar; waybar &
3
4# wofi 掛了
5killall wofi
6# wofi 只在需要時啟動，不用常駐
7
8# mako 掛了
9killall mako; mako &

systemd user unit 啟動方式：

1systemctl --user restart waybar
2systemctl --user restart mako

確認工具是否在跑：

1pgrep waybar  # 有輸出 = 在跑
2pgrep mako    # 沒輸出 = 沒在跑

預防：改 config 後重啟對應的工具確認語法正確。Waybar 的 config 是 JSON 格式，語法錯誤會導致它無法啟動——改完後先用 waybar 前台跑一次看有沒有錯誤訊息。

場景二點五：鎖屏卡死（hyprlock 異常結束）

症狀：鎖屏畫面消失但桌面沒回來，螢幕顯示 Hyprland 的失效保護訊息（「it looks like you locked your screen but the lockscreen app died」），或畫面全黑但系統有回應（SSH 能連、TTY 可能切得到也可能切不到）。

原因：鎖屏工具（Hyprlock、Swaylock）透過 Wayland 的 ext-session-lock 協議向 compositor 請求鎖定。鎖定狀態由 compositor 持有，唯一正常解鎖動作是鎖屏 client 通過認證後呼叫 unlock_and_destroy。如果鎖屏 client 在持鎖狀態下被殺（pkill、crash），compositor 沒收到認證信號，會維持鎖定並顯示失效保護畫面。這跟殺 waybar/mako 不同——那些是普通 process，殺了重啟就好；鎖屏 client 持有安全狀態，殺了反而卡住。

恢復步驟：

1. 嘗試切到另一個 TTY（Ctrl+Alt+F2）。注意：ext-session-lock 的安全語意允許 compositor 攔截 VT 切換快捷鍵，此時 TTY 切不過去，改用 SSH 從另一台機器連入
2. 允許新的鎖屏 client 接管既有的鎖：

1hyprctl --instance 0 'keyword misc:allow_session_lock_restore 1'

3. 重新拉一個鎖屏 client：

1hyprctl --instance 0 'dispatch exec hyprlock'

4. 回到鎖屏畫面，用密碼正常解鎖

判讀：loginctl show-session <id> -p LockedHint 可能顯示 LockedHint=no（logind 層認為沒鎖），但畫面仍進不去——因為擋住畫面的是 compositor 的 ext-session-lock，跟 logind 的提示是獨立的兩層。判斷畫面鎖定狀態看 compositor 層，不看 logind。

預防：測試鎖屏時備好恢復路徑（知道密碼、或預先開 SSH）。不要用殺 process 的方式結束鎖屏——要結束就走認證解鎖。自動化流程若會啟動鎖屏，把「需要人工解鎖」算進代價。鎖屏安全模型的完整說明見 Session Lock。

場景二點六：桌面 shell 畫得出來但互動死掉（進程活著卻 wedged）

症狀：bar / 狀態列還在螢幕上、看起來一切正常，但點它的按鈕（工作區切換、系統匣圖示）沒反應，keybind 叫不出啟動器（wofi / 內建 launcher）。同時焦點視窗（例如終端機）打字完全正常——鍵盤到得了應用程式，只是桌面 shell 的互動死了。

原因：這是跟場景二（工具掛了）不同的一類故障，關鍵差別在進程還活著。場景二是 process 崩潰退出（pgrep 沒輸出），殺了重啟就好；這裡的桌面 shell（如 caelestia / Quickshell）進程還在跑（pgrep 找得到、STAT 是正常的 S、在 poll 等事件、CPU 不高），但它內部的某個子系統初始化失敗了——常見是 QML scene 的某個物件因為上游錯誤沒建起來、變成 null，於是負責「keybind → 開抽屜」「bar 按鈕互動」的模組對 null 讀屬性、整條互動接線死掉。bar 之所以還畫得出來，是它還停在初始化失敗前那一幀的畫面：畫得出來不等於還活著，跟鎖屏那課（畫面有密碼框不等於真的在鎖）是同一個陷阱。

上游觸發常是渲染層。實測案例：VM 的 GPU 只提供到 GLSL 1.20，而 shell 的 shader 需要 GLES 100/300/330，pipeline 建不起來（log 狂噴 Failed to build graphics pipeline state），這次渲染失敗把 scene 初始化打斷，drawers 狀態物件變 null。

診斷（別看 pgrep，讀 shell 自己的 log）：

pgrep 在這裡會騙你——它回報「在跑」，但那不等於「在運作」。權威來源是 shell 自己的 log，而且這種 log 常常不在 journalctl、也不在你猜的路徑，要用該 shell 專屬的 log 指令：

1# caelestia 的例子：用它自己的 CLI 印 shell log
2caelestia shell -l 2>&1 | tail -40
3# 看的是 QML 的 TypeError：對 null 讀屬性 = 那個子系統死了
4#   scene: @modules/Shortcuts.qml: TypeError: Cannot read property 'launcher' of null

另一個活性探針是 shell 的 IPC 回不回真實狀態：正常時查抽屜列表會回傳名字，子系統死掉時回空——這比「進程在不在」精準得多：

1# 子系統活著 → 列出 bar/launcher/session…；死掉 → 回空
2caelestia shell ipc call drawers list

恢復步驟：重啟 shell 讓 scene 重建。以 caelestia 為例：

1caelestia shell -k     # 殺掉卡住的 shell
2caelestia shell -d     # 重新啟動（detached）

驗證修好了，看子系統回來、不是看 pgrep：重啟後 process 一定在（pgrep 本來就會有），要確認的是接線恢復——caelestia shell ipc call drawers list 從「回空」變成列出真實抽屜名、log 不再噴 null 的 TypeError。這對應「重啟成功要驗子系統狀態、不是驗 process 存在」的通用紀律。

判讀與其他場景的界線：pgrep 有輸出 + bar 畫得出來 → 別急著判「正常」；點不動 / keybind 死掉就是 wedged 的訊號，往 shell 自己的 log 查。這跟場景二（process 真的沒了、pgrep 空）、場景三（compositor 整個凍結、連終端機打字都不行）都不同——這裡 compositor 正常、焦點視窗鍵盤正常，只有 shell 的互動接線死。判「進程活著到底有沒有在運作」的通用招式，見 程序、服務與狀態怎麼判。

預防：留意 shell log 裡持續出現的 shader / 渲染 pipeline 錯誤——在 VM 或 GL 支援不足的環境，這類錯誤可能非致命地存在（shell 大致能用），但一次渲染失敗就可能打斷 scene 初始化、把互動接線弄死。VM 環境要確認 GPU 提供的 GL / GLSL 版本足夠（virtio-gpu 走 mesa/zink 提供 GL 3.3+），或在 shell 設定關掉需要高階 shader 的效果。

場景三：GPU driver hang（畫面凍結）

症狀：桌面畫面完全凍結——滑鼠不動、鍵盤不回應、Ctrl+Alt+F2 切 TTY 也沒反應或延遲很久才回應。但如果從另一台機器 SSH 進來，系統是活的，process 都在跑。

原因：GPU driver 進入異常狀態。NVIDIA 閉源驅動在 Linux 上的穩定性不如 AMD 開源驅動（amdgpu），特別是在 Wayland 環境下。常見觸發條件包括 suspend/resume 之後 GPU 沒正確恢復、某些 OpenGL/Vulkan 操作觸發 driver bug、顯示輸出切換（接上或拔掉外接螢幕）。

恢復步驟：

方法 A — 如果 TTY 能切過去：

1# 切到 TTY2
2Ctrl+Alt+F2
3
4# 殺掉 Hyprland（它會帶走所有視窗）
5killall Hyprland
6
7# 重新啟動
8Hyprland

方法 B — 如果 TTY 也凍結、但 SSH 能連：

 1# 從另一台機器 SSH 進來（需事先知道 IP，見下方預防段）
 2ssh user@machine-ip
 3
 4# 殺掉 compositor
 5killall Hyprland
 6
 7# 如果需要 reset GPU（NVIDIA，且 driver 仍回應）
 8# 前提：所有使用 GPU 的 process 已停止（compositor 已 kill）
 9sudo nvidia-smi --gpu-reset
10
11# 切回機器前面重啟 Hyprland

方法 C — 如果完全無回應，先嘗試 Magic SysRq：

Magic SysRq 是 kernel 層級的緊急操作介面，即使 userspace 完全卡死也能回應。按住 Alt+SysRq（筆電通常是 Alt+Fn+SysRq），然後依序按 R E I S U B（每個鍵間隔幾秒）：

• R — 把鍵盤從 raw mode 搶回來
• E — 對所有 process 送 SIGTERM
• I — 對所有 process 送 SIGKILL
• S — sync 所有檔案系統
• U — remount 所有檔案系統為 read-only
• B — 立即 reboot

這比直接斷電安全——sync + unmount 步驟會盡量保護磁碟上的資料。Arch Linux 預設可能停用 SysRq，需在 /etc/sysctl.d/ 設定 kernel.sysrq=1 啟用。

方法 D — 如果 SysRq 也無效，按住電源鍵強制關機：

這是最後手段。Linux 的 ext4/btrfs 檔案系統有 journal 保護，強制關機通常不會損壞檔案系統結構。但 journal 保護的是 metadata 一致性，正在寫入的使用者資料（未存檔的文件、正在下載的檔案）仍然可能遺失或損壞。重開機後正常登入 TTY、啟動 Hyprland 即可。如果開機過程有異常，用 journalctl -b -1 -p err 查看上次開機的錯誤訊息，確認是否有檔案系統修復紀錄。

預防：

• NVIDIA 用戶：關注 driver 版本的 release notes，已知有 Wayland 問題的版本避開
• 配置 suspend 後的 GPU 恢復：在 Hyprland config 或 systemd sleep hook 裡加入 GPU reset 操作
• 事先記錄機器的 IP 位址（ip addr show）或設定固定 hostname（如 mDNS 的 machine.local），桌面凍結時才有辦法從另一台機器 SSH 進來
• 考慮開啟 SSH server，出問題時可以遠端救援。開啟後應配置 key-based authentication 並停用密碼登入（PasswordAuthentication no），避免在網路上暴露密碼登入通道：

1sudo systemctl enable sshd
2sudo systemctl start sshd
3
4# 安全配置：停用密碼登入（確保已設好 SSH key 再改）
5# 編輯 /etc/ssh/sshd_config，設定 PasswordAuthentication no
6# 然後 sudo systemctl restart sshd

場景四：記憶體耗盡（OOM）

症狀：系統變得極慢，操作有明顯延遲（幾秒到幾十秒）。隨後可能某些 process 突然被殺掉——瀏覽器分頁消失、IDE 視窗關閉，嚴重時 Hyprland 本身被 OOM Killer 終止導致桌面消失。

原因：實體記憶體和 swap 都用完了。常見觸發者是瀏覽器（Chrome/Firefox 的分頁越開越多）、IDE（大型專案的 language server）、Docker container、或應用程式的記憶體洩漏。

恢復步驟：

如果還能操作：

1# 找出誰在吃記憶體
2top -o %MEM
3# 或用 htop/btop 的互動介面
4
5# 殺掉佔最多記憶體的 process
6kill <PID>

如果桌面已經被殺、在 TTY 裡：

1# 看 OOM Killer 殺了誰
2journalctl -b | grep -i "out of memory"
3journalctl -b | grep -i "oom"
4
5# 清理完後重啟桌面
6Hyprland

預防：

設定 swap（即使 RAM 夠大，swap 提供 OOM 前的緩衝時間讓你有機會手動清理 process）。RAM 16GB 以上的機器，2-4GB swap 作緩衝通常足夠：

 1# 查看是否有 swap
 2swapon --show
 3
 4# 如果沒有，建立一個 4GB 的 swap file（ext4 檔案系統）
 5sudo fallocate -l 4G /swapfile
 6sudo chmod 600 /swapfile
 7sudo mkswap /swapfile
 8sudo swapon /swapfile
 9
10# 永久生效：加入 /etc/fstab
11echo '/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab

Btrfs 檔案系統不支援 fallocate 建立 swap file。Btrfs 用戶需改用 btrfs filesystem mkswapfile 或建立專屬的 swap subvolume，具體做法參考 Arch Wiki 的 Btrfs swap 段落。

啟用 systemd-oomd（比 kernel OOM Killer 更早介入、更可控）。systemd-oomd 在 cgroup 的記憶體壓力達到閾值時就開始清理，預設配置對多數桌面場景足夠。進階調整可透過 /etc/systemd/oomd.conf 設定：

1sudo systemctl enable systemd-oomd
2sudo systemctl start systemd-oomd

場景五：Config 寫錯導致 Hyprland 啟動失敗

症狀：從 display manager（圖形登入畫面，如 SDDM、GDM）登入後立刻黑屏又回到登入畫面，或直接回到 TTY。如果從 TTY 手動執行 Hyprland，看到錯誤訊息後立即退出。

原因：Hyprland config 有語法錯誤或引用了不存在的資源。常見錯誤包括 source 指定的檔案不存在、keybind 語法寫錯、monitor 設定格式錯誤。

恢復步驟：

1. 切到 TTY（Ctrl+Alt+F2）
2. 登入後直接跑 Hyprland 看錯誤訊息：

1# 看 Hyprland 的啟動錯誤（也可用 journalctl -b | grep -i hypr）
2Hyprland
3# Hyprland 如果因 config 錯誤無法啟動，會直接印出錯誤訊息後退出

3. 根據錯誤訊息修改 config：

1# Hyprland 的主 config
2vim ~/.config/hypr/hyprland.conf
3
4# 如果用了 source 拆分，錯誤訊息會指出是哪個檔案
5vim ~/.config/hypr/keybinds.conf

4. 修完後重新啟動：

1Hyprland

常見 config 錯誤：

source 路徑錯誤——檔案不存在或路徑拼錯：

1# 確認 source 指定的檔案都存在
2grep "^source" ~/.config/hypr/hyprland.conf
3# 逐一檢查每個路徑

Monitor 設定錯誤——指定了不存在的螢幕名稱：

1# 查看系統實際的螢幕名稱
2# 在能進桌面時記下來，或用 wlr-randr
3wlr-randr

Keybind 語法錯誤——dispatcher 名稱拼錯或參數格式不對。Hyprland 的 keybind 格式是 bind = MOD, key, dispatcher, params，少一個欄位或 dispatcher 拼錯就會報錯。

預防：config 改動時用 hyprctl reload 即時測試，不要改完 config 就直接重啟 Hyprland。如果 dotfile 用 Git 管理，改壞了可以 git checkout 回退。

場景六：Suspend/resume 後桌面異常

症狀：筆電蓋上或手動 suspend 後喚醒，出現以下任一情況——螢幕黑屏但系統有反應（鍵盤背光亮）、解析度跑掉、多螢幕配置丟失（所有視窗擠到一個螢幕）、compositor 直接 crash 回到 TTY。

原因：GPU driver 在 suspend/resume 過程中需要保存和恢復 GPU 狀態。NVIDIA 閉源驅動在 Wayland 上的 suspend/resume 支援不如 AMD 開源驅動穩定，特別是多螢幕配置和高刷新率模式下容易出問題。

恢復步驟：

如果螢幕黑屏但系統有反應：

1# 切到 TTY
2Ctrl+Alt+F2
3
4# 檢查 Hyprland 是否還在跑
5pgrep Hyprland
6
7# 如果在跑但沒畫面，kill 再重啟
8killall Hyprland
9Hyprland

如果解析度或螢幕配置跑掉：

1# 在 Hyprland 內重新套用 monitor 設定
2hyprctl reload

如果 compositor 已經 crash：按場景一的步驟從 TTY 重啟。

預防：

• NVIDIA 用戶：在 /etc/modprobe.d/nvidia.conf 啟用 preserve video memory allocations：

1# /etc/modprobe.d/nvidia.conf
2options nvidia NVreg_PreserveVideoMemoryAllocations=1

同時啟用 NVIDIA 的 suspend/resume systemd service：

1sudo systemctl enable nvidia-suspend
2sudo systemctl enable nvidia-resume
3sudo systemctl enable nvidia-hibernate

• AMD 用戶：amdgpu driver 的 suspend/resume 通常開箱即用，遇到問題先更新 kernel（pacman -Syu linux）。

配置檔位置與格式

Hyprland v0.55 起，配置格式從 hyprlang（.conf）遷移到 Lua（.lua）。主配置檔是 ~/.config/hypr/hyprland.lua。如果 .lua 不存在但 .conf 存在，Hyprland 會回退讀取舊格式，但 hyprlang 已標記為棄用，後續版本會移除支援。

修改後即時生效（不需要重新登入或重啟）。第一次啟動時如果沒有配置檔，Hyprland 會自動產生範例配置。即使配置有語法錯誤，緊急快捷鍵（SUPER+Q 開 terminal、SUPER+M 離開）仍然可用。

[VM 可測試] 配置檔格式和載入行為在 VM 裡跟實機完全相同。

模組化拆分

用 Lua 原生的 require() 拆分配置：

1-- ~/.config/hypr/hyprland.lua — 主入口
2
3require("monitors")      -- 載入 monitors.lua
4require("keybinds")      -- 載入 keybinds.lua
5require("rules")         -- 載入 rules.lua
6require("autostart")     -- 載入 autostart.lua
7require("appearance")    -- 載入 appearance.lua
8require("env")           -- 載入 env.lua

require("monitors") 會從同目錄載入 monitors.lua。拆分的理由是職責分離——改 keybind 不用在千行配置裡找位置，每個子檔案可以獨立 diff 和 rollback。

從舊格式遷移

Hyprland 官方提供遷移工具：hyprlang2lua（Go，也有瀏覽器版）和 hypr-migrate。如果你是從零開始，直接用 Lua 格式。

Monitor 設定

Monitor 設定是硬體相關的核心配置，每台機器都不同。

 1-- ~/.config/hypr/monitors.lua
 2
 3hl.config({
 4    monitor = {
 5        -- 語法："name, resolution@refreshrate, position, scale"
 6        "DP-1, 2560x1440@144, 0x0, 1",
 7        "HDMI-A-1, 1920x1080@60, 2560x0, 1",
 8
 9        -- 筆電內建螢幕
10        "eDP-1, preferred, auto, 1.5",
11
12        -- 預設規則（未明確列出的螢幕）
13        ", preferred, auto, 1",
14
15        -- 鏡像模式（DP-2 鏡像 DP-1 的畫面）
16        -- "DP-2, preferred, auto, 1, mirror, DP-1",
17    },
18})

position 決定多螢幕的空間排列——0x0 是左上角原點，2560x0 表示在第一個螢幕的右邊。scale 處理 HiDPI 顯示（1.5 表示 150% 縮放）。

查詢可用的 monitor 名稱：hyprctl monitors

其他選項：

• transform, 1 — 旋轉（0=正常、1=90 度、2=180 度、3=270 度）
• vrr, 1 — 可變更新率（1=開啟、2=僅全螢幕）
• bitdepth, 10 — 10-bit 色彩

筆電合蓋行為

1-- 合蓋時關閉內建螢幕、開蓋時恢復
2-- bindl = 即使輸入鎖定也能觸發（合蓋時需要）
3hl.bindl("", "switch:on:Lid Switch", "exec", "hyprctl keyword monitor 'eDP-1, disable'")
4hl.bindl("", "switch:off:Lid Switch", "exec", "hyprctl keyword monitor 'eDP-1, preferred, auto, 1'")

[需實機測試] Monitor 位置排列、HiDPI 縮放、VRR、旋轉、多螢幕熱插拔、合蓋行為。VM 通常只有一個虛擬螢幕。

Dotfile 管理策略

Monitor 設定是典型的「機器專屬」配置。如果用 chezmoi，可以用 template 依機器名稱切換；如果用 stow，可以把 monitors.lua 排除在 Git 外、每台機器手動寫。

輸入裝置配置

 1-- ~/.config/hypr/hyprland.lua 或拆到獨立檔案
 2
 3hl.config({
 4    input = {
 5        kb_layout = "us",
 6        -- 多語系：kb_layout = "us,de",
 7        -- 切換：kb_options = "grp:alt_shift_toggle",
 8        -- Caps Lock 當 Escape：kb_options = "caps:escape",
 9        kb_options = "",
10
11        follow_mouse = 1,         -- 焦點跟隨滑鼠
12        sensitivity = 0,          -- -1.0 到 1.0（0 = 不修改）
13        accel_profile = "flat",   -- flat 或 adaptive
14
15        repeat_rate = 25,         -- 長按時每秒重複幾次
16        repeat_delay = 600,       -- 按住多久開始重複（毫秒）
17
18        touchpad = {
19            natural_scroll = true,
20            disable_while_typing = true,
21            ["tap-to-click"] = true,
22            drag_lock = false,
23            scroll_factor = 1.0,
24        },
25    },
26})

可用的 XKB options 查詢：/usr/share/X11/xkb/rules/evdev.lst 或 localectl list-x11-keymap-options。

[VM 可測試] 鍵盤 layout、repeat rate。
[需實機測試] 觸控板設定、手勢、滑鼠靈敏度/加速曲線、多鍵盤配置。

Keybind 設計

修飾鍵（Modifier）：SUPER 是哪顆鍵

keybind 由「修飾鍵 + 按鍵」組成，Hyprland 配置裡最常當主修飾鍵的是 SUPER。SUPER 是 X11/Wayland 對 Meta 鍵的稱呼，在不同鍵盤上是不同的實體鍵：

• PC 鍵盤：Windows 鍵（⊞，通常在 Ctrl 與 Alt 之間）。
• Mac 鍵盤：Command 鍵（⌘）。

其他常見修飾鍵：SHIFT、CTRL（Control）、ALT（Mac 上是 Option ⌥）。組合寫法用空格串，例如 "SUPER SHIFT"。選 SUPER 當主修飾鍵是慣例——它幾乎不跟應用程式本身的快捷鍵衝突（應用多用 Ctrl / Alt）。

在 Mac 上跑虛擬機時，實體 ⌘ 會對應到 guest 的 SUPER，但 macOS 會先攔截部分 ⌘ 組合——這層 VM 專屬的坑見 VM 環境設定。

Bind 類型

Hyprland 提供多種 bind 函式，處理不同互動模式：

[VM 可測試] 所有 keybind 邏輯和配置語法。

基本操作

 1-- ~/.config/hypr/keybinds.lua
 2
 3-- 基本操作
 4hl.bind("SUPER", "Return", "exec", "kitty")
 5hl.bind("SUPER", "Q", "killactive")
 6hl.bind("SUPER", "D", "exec", "wofi --show drun")
 7hl.bind("SUPER", "F", "fullscreen", "0")
 8hl.bind("SUPER SHIFT", "Space", "togglefloating")
 9
10-- 焦點移動（vim 風格）
11hl.bind("SUPER", "H", "movefocus", "l")
12hl.bind("SUPER", "J", "movefocus", "d")
13hl.bind("SUPER", "K", "movefocus", "u")
14hl.bind("SUPER", "L", "movefocus", "r")
15
16-- 視窗移動
17hl.bind("SUPER SHIFT", "H", "movewindow", "l")
18hl.bind("SUPER SHIFT", "J", "movewindow", "d")
19hl.bind("SUPER SHIFT", "K", "movewindow", "u")
20hl.bind("SUPER SHIFT", "L", "movewindow", "r")
21
22-- 視窗大小調整（長按連續觸發）
23hl.binde("SUPER CTRL", "H", "resizeactive", "-20 0")
24hl.binde("SUPER CTRL", "J", "resizeactive", "0 20")
25hl.binde("SUPER CTRL", "K", "resizeactive", "0 -20")
26hl.binde("SUPER CTRL", "L", "resizeactive", "20 0")
27
28-- 滑鼠綁定：SUPER + 左鍵拖曳移動、右鍵拖曳調整大小
29hl.bindm("SUPER", "mouse:272", "movewindow")
30hl.bindm("SUPER", "mouse:273", "resizewindow")
31
32-- Workspace 切換
33hl.bind("SUPER", "1", "workspace", "1")
34hl.bind("SUPER", "2", "workspace", "2")
35hl.bind("SUPER", "3", "workspace", "3")
36hl.bind("SUPER", "4", "workspace", "4")
37hl.bind("SUPER", "5", "workspace", "5")
38hl.bind("SUPER", "6", "workspace", "6")
39hl.bind("SUPER", "7", "workspace", "7")
40hl.bind("SUPER", "8", "workspace", "8")
41hl.bind("SUPER", "9", "workspace", "9")
42
43-- 把視窗送到指定 workspace
44hl.bind("SUPER SHIFT", "1", "movetoworkspace", "1")
45hl.bind("SUPER SHIFT", "2", "movetoworkspace", "2")
46hl.bind("SUPER SHIFT", "3", "movetoworkspace", "3")
47-- 以此類推
48
49-- 螢幕截圖
50hl.bind("", "Print", "exec", "grimblast copy area")
51hl.bind("SUPER", "Print", "exec", "grimblast copy output")
52
53-- 多螢幕焦點切換
54hl.bind("SUPER", "comma", "focusmonitor", "l")
55hl.bind("SUPER", "period", "focusmonitor", "r")
56hl.bind("SUPER SHIFT", "comma", "movewindow", "mon:l")
57hl.bind("SUPER SHIFT", "period", "movewindow", "mon:r")

設計原則

• SUPER（Windows/Command 鍵）當 modifier，避免跟應用程式快捷鍵衝突
• 方向操作統一用 vim 的 HJKL，降低記憶負擔
• modifier 分層：SUPER 是焦點、SUPER+SHIFT 是移動、SUPER+CTRL 是調整大小
• 常用操作（開 terminal、關視窗、切 workspace）放在最順手的位置

Submap：模態快捷鍵

Submap 類似 vim 的模式切換——進入某個 submap 後，快捷鍵的意義改變，直到離開。適合需要連續操作的場景（如調整大小）：

 1-- 按 SUPER+R 進入 resize 模式
 2hl.bind("SUPER", "R", "submap", "resize")
 3
 4-- 定義 resize 模式的快捷鍵
 5hl.submap("resize")
 6hl.binde("", "H", "resizeactive", "-20 0")
 7hl.binde("", "L", "resizeactive", "20 0")
 8hl.binde("", "K", "resizeactive", "0 -20")
 9hl.binde("", "J", "resizeactive", "0 20")
10hl.bind("", "escape", "submap", "reset")   -- Escape 離開
11hl.submap("reset")

進入 resize 模式後，直接按 HJKL（不需要 modifier）就能持續調整大小，按 Escape 回到正常模式。

媒體鍵與硬體鍵

 1-- 音量（鎖屏時也能用、長按連續觸發）
 2hl.bindel("", "XF86AudioRaiseVolume", "exec", "wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%+")
 3hl.bindel("", "XF86AudioLowerVolume", "exec", "wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%-")
 4hl.bindl("", "XF86AudioMute", "exec", "wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle")
 5hl.bindl("", "XF86AudioMicMute", "exec", "wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle")
 6
 7-- 亮度
 8hl.bindel("", "XF86MonBrightnessUp", "exec", "brightnessctl s 10%+")
 9hl.bindel("", "XF86MonBrightnessDown", "exec", "brightnessctl s 10%-")
10
11-- 媒體播放
12hl.bindl("", "XF86AudioPlay", "exec", "playerctl play-pause")
13hl.bindl("", "XF86AudioNext", "exec", "playerctl next")
14hl.bindl("", "XF86AudioPrev", "exec", "playerctl previous")

[需實機測試] 媒體鍵（XF86Audio*）、亮度鍵（XF86MonBrightness*）、合蓋開關——這些依賴實體硬體送出正確的 keycode。VM 鍵盤通常沒有這些鍵。

環境變數

環境變數在 hl.config() 的 env 區段設定，影響 Hyprland 自身和其下執行的應用程式：

 1-- ~/.config/hypr/env.lua
 2
 3hl.config({
 4    env = {
 5        -- 游標主題
 6        "XCURSOR_SIZE, 24",
 7        "XCURSOR_THEME, Bibata-Modern-Classic",
 8        "HYPRCURSOR_SIZE, 24",
 9        "HYPRCURSOR_THEME, Bibata-Modern-Classic",
10
11        -- Qt 應用程式
12        "QT_AUTO_SCREEN_SCALE_FACTOR, 1",
13        "QT_QPA_PLATFORM, wayland;xcb",
14        "QT_QPA_PLATFORMTHEME, qt5ct",
15        "QT_WAYLAND_DISABLE_WINDOWDECORATION, 1",
16
17        -- GTK 應用程式
18        "GDK_BACKEND, wayland,x11,*",
19
20        -- XDG session
21        "XDG_CURRENT_DESKTOP, Hyprland",
22        "XDG_SESSION_TYPE, wayland",
23        "XDG_SESSION_DESKTOP, Hyprland",
24
25        -- Electron 應用程式（VS Code, Discord 等）
26        "ELECTRON_OZONE_PLATFORM_HINT, auto",
27
28        -- Firefox
29        "MOZ_ENABLE_WAYLAND, 1",
30    },
31})

NVIDIA 專用環境變數

如果使用 NVIDIA 顯卡，需要額外設定（AMD 和 Intel 不需要）：

 1-- 只在 NVIDIA 機器上加這些
 2hl.config({
 3    env = {
 4        "LIBVA_DRIVER_NAME, nvidia",
 5        "GBM_BACKEND, nvidia-drm",             -- Firefox 若崩潰就移除這行
 6        "__GLX_VENDOR_LIBRARY_NAME, nvidia",
 7        "NVD_BACKEND, direct",
 8    },
 9    cursor = {
10        no_hardware_cursors = true,             -- NVIDIA 常見的游標問題修正
11        allow_dumb_copy = true,
12    },
13})

[VM 不適用] NVIDIA 環境變數和驅動設定在 VM 裡無意義——VM 使用 virtio-gpu 或軟體渲染。這些設定只在實體 NVIDIA 機器上測試。

VM 專用環境變數

在 VM（UTM/QEMU）裡跑 Hyprland 需要額外的回退設定：

1-- 只在 VM 裡加，實機要移除
2hl.config({
3    env = {
4        "WLR_RENDERER_ALLOW_SOFTWARE, 1",
5        "LIBGL_ALWAYS_SOFTWARE, 1",
6        "WLR_NO_HARDWARE_CURSORS, 1",
7    },
8})

[已驗證] Hyprland 0.55（Aquamarine 渲染後端）+ UTM virtio-gpu-gl-pci 實測：使用 GPU 加速時不需要 WLR_RENDERER 或 LIBGL_ALWAYS_SOFTWARE，Hyprland 自動走 VirGL/Venus 硬體路徑。WLR_NO_HARDWARE_CURSORS 仍需要（virtio-gpu 不支援硬體 cursor）。完整 VM 設定見 VM 環境設定與測試矩陣。

Hyprlock 是 Hyprland 配套的鎖屏工具，支援模糊背景、自定義佈局：

 1# ~/.config/hypr/hyprlock.conf
 2
 3background {
 4    monitor =
 5    path = screenshot
 6    blur_passes = 3
 7    blur_size = 8
 8}
 9
10input-field {
11    monitor =
12    size = 250, 50
13    outline_thickness = 2
14    outer_color = rgba(137, 180, 250, 1)
15    inner_color = rgba(30, 30, 46, 1)
16    font_color = rgba(205, 214, 244, 1)
17    placeholder_text = <i>Password...</i>
18    fade_on_empty = true
19    position = 0, -50
20    halign = center
21    valign = center
22}
23
24label {
25    monitor =
26    text = $TIME
27    font_size = 64
28    font_family = MesloLGS Nerd Font
29    color = rgba(205, 214, 244, 1)
30    position = 0, 80
31    halign = center
32    valign = center
33}

鎖屏一旦啟動，桌面的「鎖定」狀態由 compositor 透過 Wayland 的 ext-session-lock 協議持有，殺掉鎖屏 process 不等於解鎖。鎖屏的安全模型與測試時的注意事項見 Session Lock。

配色系統的統一管理

Rice 的視覺品質取決於配色一致性。散亂的色碼（waybar 用一套、wofi 用另一套、mako 又一套）是桌面看起來「雜」的最常見原因。

管理方式：

選定一套配色方案。Catppuccin、Tokyo Night、Gruvbox、Nord 是目前最多 Linux ricer 使用的方案，每一套都有完整的色彩定義和各工具的預設配置。

建立配色變數檔。把色碼集中到一個檔案，其他配置引用它：

 1# ~/.config/hypr/colors.conf
 2$rosewater = rgb(f5e0dc)
 3$flamingo  = rgb(f2cdcd)
 4$pink      = rgb(f5c2e7)
 5$mauve     = rgb(cba6f7)
 6$red       = rgb(f38ba8)
 7$maroon    = rgb(eba0ac)
 8$peach     = rgb(fab387)
 9$yellow    = rgb(f9e2af)
10$green     = rgb(a6e3a1)
11$teal      = rgb(94e2d5)
12$sky       = rgb(89dceb)
13$sapphire  = rgb(74c7ec)
14$blue      = rgb(89b4fa)
15$lavender  = rgb(b4befe)
16$text      = rgb(cdd6f4)
17$subtext1  = rgb(bac2de)
18$overlay0  = rgb(6c7086)
19$surface0  = rgb(313244)
20$base      = rgb(1e1e2e)
21$mantle    = rgb(181825)
22$crust     = rgb(11111b)

Hyprland 的 source 可以引用這些變數。Waybar 和 Wofi 的 CSS 無法直接引用 Hyprland 變數，但可以用 build script 或 template 工具（如 pywal、flavours）從一份主設定產生各工具的配色。

換配色方案時需要改的檔案清單：

• Hyprland appearance.conf（邊框、陰影顏色）
• Waybar style.css
• Wofi/Rofi style.css
• Mako config
• Hyprlock config
• Terminal emulator 配色
• Neovim colorscheme
• GTK theme（影響 GUI 應用程式的外觀）

把這個清單記在 dotfile repo 的 README 裡，換主題時有對照不會漏改。

GTK / Qt 主題

Linux 的 GUI 應用程式分兩大陣營：GTK（GNOME 系）和 Qt（KDE 系）。平鋪式 WM 不自帶主題引擎，需要手動設定：

1# GTK 設定
2# ~/.config/gtk-3.0/settings.ini
3[Settings]
4gtk-theme-name=Catppuccin-Mocha-Standard-Blue-Dark
5gtk-icon-theme-name=Papirus-Dark
6gtk-font-name=Noto Sans CJK TC 11
7gtk-cursor-theme-name=Bibata-Modern-Classic

Qt 應用程式用 qt5ct / qt6ct 設定，或用 Kvantum 主題引擎統一風格。

Dotfile 結構對應

Rice 涉及的工具最多——waybar、wofi、mako、hyprlock、GTK 各自是獨立的 stow package。邊界切在「一個工具一個 package」，換主題時才能按需更新而不影響其他工具。themes/ 放共用的配色變數，不屬於任何單一工具：

 1~/dotfiles/
 2├── waybar/
 3│   └── .config/
 4│       └── waybar/
 5│           ├── config.jsonc
 6│           └── style.css
 7├── wofi/
 8│   └── .config/
 9│       └── wofi/
10│           ├── config
11│           └── style.css
12├── mako/
13│   └── .config/
14│       └── mako/
15│           └── config
16├── hyprlock/
17│   └── .config/
18│       └── hypr/
19│           └── hyprlock.conf
20├── gtk/
21│   └── .config/
22│       └── gtk-3.0/
23│           └── settings.ini
24└── themes/
25    └── colors.conf          # 集中配色定義

Rice 的投資報酬判讀

Rice 可以投入的時間沒有上限。務實的分界線：

• 功能性配置（waybar 顯示正確資訊、wofi 能搜到 app、通知會跳出來）：投入一到兩小時，這是桌面可用的前提
• 視覺統一（全域配色一致、字型統一、圓角/間距協調）：投入半天到一天，這是「好看」跟「雜亂」的分界
• 精雕細節（自定義動畫曲線、pixel-perfect 對齊、自製 widget）：時間無底洞，看個人興趣

前兩層是值得做的——它們改善每天使用的體驗。第三層是嗜好領域，跟「把車改到完美」是同一種動力，不需要理性上的正當性。

工具依使用環境分三組，因為同一個需求在不同環境下的可用工具與取捨不同：

為什麼把工具當成「選項」來教

以搜尋為例：多數教材教 grep 跟 find，但實務上很多開發者改用 ripgrep（rg）跟 fd——更快、預設尊重 .gitignore、輸出更好讀；互動式搜尋再加 fzf。不同情境有更省力的選擇，grep 本身並沒有錯。把工具當成「有取捨的選項」來認識，你才能在對的情境挑對工具，而不是永遠只會預設的那個。

同理，圖形桌面下要一個檔案管理員，Thunar、PCManFM-Qt、Nemo 各有相依與桌面耦合的取捨；桌面環境本身也有 GNOME/KDE/Hyprland 等多種版本，各自還有可擴充的元件。這些「選項」的判讀，正是這個系列要補的。

在其他情境的落點

工具選擇不是孤立的，它接在具體任務上：

• 安裝與機器初始化——新機器要裝哪些工具、進 dotfile 套件清單一次裝齊。
• 除錯與診斷——除錯用的診斷工具（busctl / journalctl / ip neigh 等）在各情境怎麼用。
• Dotfile 管理——選好的工具怎麼把配置檔版控、跨機器同步。

核心：終端機多工器

遠端工作的地基是終端機多工器（tmux / zellij）——它把你的 session 常駐在遠端，SSH 斷了 session 不受影響，重連 attach 就回到原狀。這也是把長任務交給遠端機器無人值守跑的前提。深入配置與比較見 CLI 環境工具 裡的多工器篇：

• tmux 持久化與基礎——最通用的多工器，session 持久化的核心概念。
• zellij 分頁與 pane——較新、開箱即用、內建佈局的多工器。
• zellij 遠端 web 客戶端——從瀏覽器連遠端 session 的路徑。

連線與同步工具

多工器保住 session 之後，還有兩塊獨立的能力：連線層（怎麼接上遠端、斷了怎麼辦）與同步層（本地與遠端的檔案怎麼一致）。這兩塊各有多個工具、解不同弱點，挑錯會很痛——連線存活、可達性、檔案一致是三層不同的問題。

• 遠端連線與同步工具選型——ssh / mosh（漫遊不斷線）/ autossh（自動重連）、tailscale / wireguard（NAT 後可達性）、rsync / sshfs / mutagen（三種同步語義）、IDE remote 模式的定位與取捨。

低頻寬 / 手機連線下的介面

頻寬低或從手機 / 平板連線時，只傳純文字的 TUI 介面（ASCII / Unicode 製圖，不傳影像）最穩。監控、圖表、檔案瀏覽、資料庫操作都有這類工具，整理在 CLI 環境工具。

遠端連線與 session 的除錯

遠端連線本身出問題時（連不上、終端機噴亂碼、要從 SSH 操控圖形桌面），是診斷問題而非工具選擇問題，見 除錯與診斷：遠端連線與終端機問題 與 機器連不到或起不來。

把機器交給遠端無人值守

設好讓遠端機器在你離開後自己跑完長任務、把成果送回來，見 Linux 安裝與機器初始化：讓機器跑無人值守的長任務。

遠端機器突然連不上：先分清是哪一段斷

一台昨天還能 SSH 的機器今天連不上，第一步是確認「網路層通不通」，跟「SSH 服務在不在」分開。連線在 TCP 就 timeout（連 port 22 卡住沒回應），多半是網路層或機器沒在跑；連線有回應但被拒（Connection refused），是網路通、但那台機器上沒有服務在聽 port 22。

對虛擬機或同網段的機器，一個很有用的權威來源是鄰居表（IP 對 MAC 的對應）。要填起來需要對方在鏈路層有回應，所以它直接反映「對方在不在」。用 ip neigh 看目標 IP 的條目——優先用 ip neigh 而不是 arp -a，因為 ip（iproute2）在現代最小系統一定有，arp（net-tools）常常沒裝、跑了會 command not found 反而誤導。如果狀態是 INCOMPLETE（arp -a 顯示的是 incomplete），代表這個 IP 在鏈路層上根本沒有機器回應——不是 SSH 的問題，是那台機器的網路沒起來、或根本沒在跑。一個實際案例：一台虛擬機 SSH timeout，鄰居表顯示整個網段的 guest 位址全是 incomplete、只有閘道（宿主那側的橋接介面）是好的——這就定位到「宿主的橋沒問題，但橋的另一頭沒有 VM 在講話」，方向立刻從「調 SSH」轉到「去看 VM 的網路或開機狀態」。

定位到「機器在跑但網路沒起來」後，去那台機器的主控台（不是 SSH，SSH 正是連不上的東西）確認：ip -brief a 看有沒有拿到 IP、systemctl status <網路服務>（dhcpcd / systemd-networkd）看網路服務起了沒，需要時 sudo systemctl restart <網路服務> 重拉。IP 回來、鄰居表的條目從 incomplete 變成有 MAC，就通了。

還有一個常見誤區是 IP 變了。SSH 的別名、金鑰、known_hosts 都綁在特定機器身分上；換機器 / 重裝 / DHCP 重配後 IP 或 host key 變了，用舊別名會連錯或被 host key 檢查擋。這條的判讀與修法（ssh user@新IP 直連、ssh-keygen -R）見 外部連入與無 key 的 bootstrap 路徑。

網路通、但域名解析不了

有一種故障看起來像「網路壞了」，其實是 DNS 解析斷了：能連 IP、卻連不上任何用域名的東西——ping 8.8.8.8 通、但 ping google.com、pacman -Sy、curl https://... 全失敗。判讀要跟前面「網路沒起來」分開，因為網路層是通的，斷的是「域名 → IP」這一步。權威檢查：ping <IP> 通而 ping <域名> 不通、或 getent hosts <域名>（resolvectl query <域名> 若有 systemd-resolved）解不出位址，就定位到 DNS。常見成因是 /etc/resolv.conf 沒有可用的 nameserver（新裝或網路重設後沒填），或負責 DNS 的服務沒起來。修：確認 /etc/resolv.conf 有一行 nameserver（如 nameserver 1.1.1.1）、systemctl status systemd-resolved（若用它）。這一層在剛裝好的最小系統特別常撞到——ip -brief a 明明有 IP，pacman 或 bootstrap 卻抓不到套件，看起來像「網路好好的卻裝不了東西」，根因是 DNS 沒設。

虛擬機開不起來：分清 guest 內部還是宿主側

虛擬機開機失敗時，關鍵判斷是「錯誤來自 guest 內部（作業系統層）還是宿主側（虛擬化軟體 / QEMU 層）」。宿主側的錯誤訊息通常來自虛擬機軟體本身、在 guest 還沒開始開機前就跳出來，跟 guest 裡裝了什麼無關。

一個實例是 QEMU 報「找不到某個 ROM 檔」（例如 efi-virtio.rom）而拒絕啟動。第一反應可能是「檔案不見了要重裝」，但正確的第一步是去確認那個檔在不在——實際去虛擬機軟體的安裝目錄裡找（find <安裝目錄> -name '<rom名>'），會發現 ROM 檔明明就在。既然檔案在，「找不到」就不是缺檔，是 QEMU 執行時在它預期的路徑下找不到——成因隨宿主 OS 不同。在 macOS + UTM 宿主上，最常見的是 Gatekeeper app translocation：帶隔離屬性的 app 被搬到一個隨機唯讀路徑跑，讓 QEMU 解析資源的相對路徑失效，明明存在的檔案在那個執行路徑下就找不到。在 Linux 宿主上（沒有 translocation 這回事），同樣的「找不到 ROM」通常是缺對應套件（ovmf / ipxe-roms / edk2-ovmf）、libvirt XML 指的 ROM 路徑錯、或檔案權限不對——一樣先確認檔在哪、QEMU 是用哪個路徑去找。

另外兩個常見的「VM 起不來」故障也順手一起排除，它們不會特定產生「找不到 ROM」但常伴隨出現：上一次崩潰殘留的 helper 行程卡著（pgrep -af 'qemu|<虛擬機軟體名>' 找，沒清乾淨會佔住資源），以及宿主磁碟滿（df -h，啟動要寫暫存 / 狀態檔）。多數情況下，完全退出虛擬機軟體（連殘留 helper 一起清）+ 清出宿主磁碟空間 + 重新啟動，就恢復了。

判讀通則：虛擬機開不起來，先讀錯誤訊息判斷是 guest 還是宿主側；宿主側報「找不到某資源」而資源其實存在時，往「QEMU 是用哪個路徑找、那條路徑對不對」查（macOS 是 translocation、Linux 是缺套件 / 路徑 / 權限），再順手排除殘留行程與磁碟滿，而不是急著重裝。

磁碟滿是連鎖故障的共同根因

很多看起來各自獨立的故障，共同根因是磁碟滿。磁碟一滿，寫入就會失敗，而系統裡太多東西依賴寫入：SSH session 可能因為寫不了而被斷、正在跑的編譯 / 安裝會中途失敗、log 寫不進去、虛擬機狀態檔存不下導致連不上或開不起來。所以當你在短時間內撞到「連線斷了 + 某個任務失敗 + 服務怪怪的」這種一串症狀時，df -h 應該是很早就要做的檢查——一個廉價的檢查就可能一次解釋掉全部。

這裡有一個容易搞錯的點：清錯了地方。宿主跟 guest 是兩個獨立的檔案系統；虛擬機的宿主磁碟滿，跟 guest 內部磁碟滿，是兩件事。如果你 SSH 進 guest 裡 df 看到還有空間就以為沒事，但真正滿的是宿主的磁碟，那問題不會解決。判讀時要分清這串故障是「哪一台機器的哪個檔案系統」滿了——在宿主上 df -h 看宿主、在 guest 裡 df -h 看 guest，兩邊都要確認。清空間也要清在對的那一側。

判讀路由

• SSH timeout（TCP 卡住）→ 網路層或機器沒跑，查 ip neigh（INCOMPLETE = 對方沒回應）→ 去主控台看 ip -brief a / 網路服務。
• Connection refused → 網路通、但沒有服務在聽 → 去機器上確認 sshd 起了沒。
• 能 ping IP、不能用域名（pacman / curl 失敗）→ DNS 解析問題，查 /etc/resolv.conf 有沒有 nameserver、systemd-resolved 起了沒，不是網路層斷。
• 連錯 / host key 被擋 → IP 或身分變了，見 外部連入與無 key 的 bootstrap 路徑。
• 虛擬機開不起來、宿主側報「找不到資源」但資源在 → 主因查路徑隔離，再排除殘留行程（pgrep -af 'qemu\|...'）/ 磁碟。
• 一串症狀同時發生 → 早點 df -h，宿主與 guest 兩側都查，磁碟滿常是共同根因。

連不上只是最終症狀，真正的定位靠網路表、服務狀態、資源用量這些權威來源一層層往回推——完整的判讀紀律見 診斷心法。

這層落差最常在你跑自動化腳本時引爆。一支 bootstrap script 的第一行可能就是 sudo pacman -S ...，在一台連 sudo 都沒有的機器上，它連第一步都跨不過去。所以裝好系統後、跑任何自動化之前，先過一輪工具驗證，把缺的補上。

sudo：先有雞還是先有蛋

sudo 是最容易被假設存在、卻最常缺席的工具，而且它的缺席有一個結構性的麻煩：補它的動作本身需要 root 權限。最小安裝通常不含 sudo。某些安裝程式（如本例的 archboot）即使你勾了「把這個使用者設為管理員」，那個動作也往往只是把使用者加進 wheel 群組，並沒有真的裝上 sudo、也沒有啟用 sudoers 裡 wheel 群組的授權行。結果就是使用者「名義上是管理員」，但系統裡並沒有 sudo 這支指令。

這形成一個先有雞還是先有蛋的關卡：bootstrap script 要靠 sudo 來裝套件，但 sudo 自己得先存在。它的解法不能是「把 sudo 寫進套件清單」——那份清單正是靠 sudo 來安裝的。sudo 只能是「跑 bootstrap 之前的前置」，用 root 身分手動補上（su - 成為 root、echo > 檔案 重導向、chmod 設權限這些基礎操作不熟的話，見 安裝過程用到的基礎操作）：

1su -                                          # 切到 root（輸入 root 密碼）
2pacman -S --needed sudo                        # root 身分裝 sudo，不需要 sudo
3echo '%wheel ALL=(ALL:ALL) ALL' > /etc/sudoers.d/10-wheel   # 啟用 wheel 群組授權
4chmod 440 /etc/sudoers.d/10-wheel
5visudo -c                                      # 驗證 sudoers 語法，印 parsed OK 才安全
6exit

切回一般使用者後用 sudo -v 確認——能輸入密碼、沒報「不在 sudoers 檔」就成。這一步揭示一條通則：凡是 bootstrap 自身要依賴的工具，都不能由 bootstrap 來裝，必須當成前置先備好。sudo 是這類前置最典型的一個。

上面的指令以 Arch 的 pacman 為例。Fedora 用 dnf、Debian/Ubuntu 用 apt；而 Debian 系的桌面與伺服器映像多半預設就裝了 sudo、也設好了授權，這個缺口主要出現在刻意精簡的 minimal 安裝。換句話說「sudo 是前置」這條判讀軸跨發行版成立，但「你這台到底缺不缺」要靠驗證、不是假設。

which：腳本裡的隱形地雷

which 是另一個最小系統常缺、卻被腳本大量引用的指令，它的缺席會以一種隱晦的方式讓腳本出錯。很多腳本用 $(which zsh) 之類的寫法取一支程式的完整路徑；在沒有 which 的系統上，這個命令替換會吐出空字串，而下游拿到空字串的指令可能不會立刻報「找不到 which」，而是報一個看似無關的錯。實測中就遇過 chsh -s "$(which zsh)" 因為 which 不存在而變成 chsh -s ""，最後報的是 chsh: shell must be a full path name——錯誤訊息完全沒提到真正的元兇。

正確的做法是用 command -v 取代 which。command -v 是 POSIX 規範的 shell 內建，不依賴任何外部套件，在最小系統上一定存在。

1command -v zsh        # 印出 /usr/bin/zsh；找不到則回傳非零、不印東西

這條判讀對你自己寫的腳本是「把 which 全換成 command -v」，對別人的腳本是「在缺 which 的系統上，先補 which 套件或改腳本」。它跟 sudo 的差別在於：which 的缺席會悄悄製造一個誤導性的下游錯誤，而不是當場大聲報錯，所以更值得在驗證階段主動排掉。

其他常缺的工具

除了 sudo 與 which，最小系統還常缺幾類在自動化裡會用到的工具，各有各的補法。它們不像 sudo 是硬前置，但缺了會在特定步驟卡住。

rsync 的缺席要特別點出，因為它常被當成理所當然的傳輸工具。最小系統沒有它時，第一次把檔案弄進機器可以用兩邊都有的 tar 搭配 SSH 過渡：

1tar czf - --exclude '.git' . | ssh user@host 'mkdir -p ~/dest && tar xzf - -C ~/dest'

這條的好處是不依賴目標機有 rsync；缺點是它每次都傳全部、沒有 rsync 的增量。在反覆同步的工作流裡，值得早點把 rsync 補進套件清單換取增量傳輸。

ca-certificates 最容易在下一步咬人。最小系統可能沒有 CA 信任根，這時任何 HTTPS 連線——包括下一篇主推的「公開 repo 用 HTTPS clone」——會在 TLS 憑證驗證直接失敗，而錯誤訊息常指向 SSL handshake 而非「缺信任根」，容易誤判成網路問題。打算走 HTTPS 取得 dotfile 的機器，先確認 ca-certificates 在。git 與 curl 同理：它們是 bootstrap 取得程式碼的基本工具，下面的驗證迴圈也會檢查，最小系統若沒有要一併補。

剩下兩項的缺席各有觸發時機。hostname 只在腳本明確呼叫它取主機名時才會浮現缺失，而用 hostnamectl 或直接讀 /etc/hostname 可以繞過，所以它常被當成「補了省事、不補也有替代」的軟缺口。編譯工具鏈則是在你要從原始碼或社群套件庫編譯時才需要——純跑預編譯套件的機器可以不裝，但只要你的 dotfile 流程會編譯任何東西（例如從社群套件庫裝桌面元件），它就得進清單。

系統性的驗證

裝好系統後先跑一輪集中驗證、把缺口一次盤出來，比等腳本跑到一半才逐一踩雷省事。驗證的對象是「你接下來的流程會用到、但最小系統可能沒有」的工具。

1for cmd in sudo git curl rsync tar zsh; do
2  if command -v "$cmd" >/dev/null 2>&1; then
3    echo "OK   $cmd"
4  else
5    echo "缺   $cmd"
6  fi
7done

這段刻意用 command -v 來檢查（而不是 which），因為要檢查的對象之一正是「外部工具在不在」，用一個一定存在的內建來檢查才不會自己先掛掉。盤出來的缺口分兩類處理：bootstrap 自身依賴的（如 sudo）當前置手動補；其餘的（如 rsync、編譯工具）進套件清單，交給 bootstrap 一起裝。

跟 Bootstrap 套件清單的界線

這篇的驗證跟 模組八的 bootstrap script 設計 是兩件互補的事，界線在「假設」上。bootstrap script 的套件清單假設一個前提：機器已經有能力執行安裝（有 sudo、有 package manager、清單裡的東西都能被裝上）。這篇處理的正是那個前提成立之前的階段——最小系統到底有沒有滿足那些假設，缺的補上，讓 bootstrap 的假設變成事實。

換句話說，套件清單回答「這台機器最終要有哪些套件」，工具驗證回答「這台機器現在夠不夠資格開始跑那份清單」。把兩者分清楚，才不會把 sudo 這種前置誤塞進靠 sudo 安裝的清單裡。

下一步

工具補齊、機器有能力執行安裝之後，你還困在一個地方：擠在機器的主控台手打。怎麼從舒適的本機終端機操作它，以及還沒有 SSH key 時怎麼把 dotfile 弄進去，外部連入、SSH key 與無 key 的 bootstrap 路徑 處理這兩件事。

journalctl：系統日誌的主要入口

systemd 的日誌系統（journal）集中收錄所有 service、kernel、user session 的 log。journalctl 是查詢這些日誌的指令。

基本用法

 1# 本次開機的所有日誌
 2journalctl -b
 3
 4# 本次開機的錯誤以上等級（err + crit + alert + emerg）
 5journalctl -b -p err
 6
 7# 本次開機，只看最後 50 行
 8journalctl -b -n 50
 9
10# 上一次開機的日誌（如果問題發生在上次開機、這次重開後想查）
11journalctl -b -1
12
13# 即時跟蹤新 log（類似 tail -f）
14journalctl -f

過濾特定來源

 1# 只看 Hyprland 相關
 2journalctl -b | grep -i hypr
 3
 4# 只看特定 systemd user unit
 5journalctl --user -u waybar -b
 6
 7# 只看 kernel 訊息（等同 dmesg）
 8journalctl -b -k
 9
10# 只看某個 process 的 log（用 PID）
11journalctl _PID=12345

時間範圍過濾

1# 最近 10 分鐘的 log
2journalctl --since "10 min ago"
3
4# 指定時間區間
5journalctl --since "2026-06-30 14:00" --until "2026-06-30 14:30"

dmesg：Kernel 層訊息

dmesg 顯示 kernel ring buffer 的內容——硬體偵測、driver 載入、硬體錯誤這些 kernel 層面的事件。排查 GPU driver 問題、USB 裝置問題、磁碟錯誤時需要看這裡。

 1# 所有 kernel 訊息（帶時間戳記）
 2dmesg -T
 3
 4# 只看錯誤和警告
 5dmesg -T --level=err,warn
 6
 7# GPU 相關（NVIDIA）
 8dmesg -T | grep -i nvidia
 9
10# GPU 相關（AMD）
11dmesg -T | grep -i amdgpu
12
13# USB 相關（鍵盤滑鼠突然不回應時看這裡）
14dmesg -T | grep -i usb

GPU driver 問題在 dmesg 裡的嚴重度差異很大：

一般 GPU hang（driver 嘗試自動恢復）：

1[  123.456] nvidia-modeset: ERROR: ...
2[  123.789] NVRM: Xid (PCI:0000:01:00): 79, pid=1234, ...
3[  124.000] amdgpu: GPU reset begin!
4[  124.500] amdgpu: GPU reset succeeded

NVIDIA 的 Xid 錯誤代碼表示不同類型的 GPU 錯誤。常見的 Xid 79 是 GPU fallback，Xid 31 是 GPU setup failure。完整代碼表可在 NVIDIA 官方文件搜尋「Xid Errors」。

硬體層級故障（嚴重，可能需要檢查硬體）：

1[  123.789] NVRM: Xid (PCI:0000:01:00): 79, pid=1234, GPU has fallen off the bus

GPU has fallen off the bus 表示 GPU 跟主機板的 PCIe 連線完全中斷。偶發一次可能是 driver 問題，反覆出現通常是硬體故障（PCIe 供電不足、顯卡接觸不良、過熱）。

hyprctl：Hyprland 的 Runtime 狀態查詢

hyprctl 是 Hyprland 提供的命令列控制工具，可以在 compositor 運行中查詢狀態和執行操作。只有在 Hyprland 正在跑的時候才能使用。

 1# 目前所有視窗的資訊
 2hyprctl clients
 3
 4# 目前的 monitor 設定
 5hyprctl monitors
 6
 7# 目前的 workspace 資訊
 8hyprctl workspaces
 9
10# Hyprland 版本和 build 資訊
11hyprctl version
12
13# 重新載入 config（不重啟 compositor）
14hyprctl reload
15
16# 查看上一次 config reload 是否有錯誤
17hyprctl systeminfo

hyprctl reload 是測試 config 變更的安全方式。如果 config 有語法錯誤，reload 會報錯但 compositor 繼續用舊 config 跑，不會崩潰。

systemctl：Service 狀態管理

桌面環境的工具（waybar、mako 等）如果用 systemd user unit 管理，可以用 systemctl --user 查看狀態和重啟。

 1# 查看某個 user service 的狀態
 2systemctl --user status waybar
 3
 4# 輸出範例：
 5# waybar.service - Highly customizable Wayland bar
 6#    Loaded: loaded (/usr/lib/systemd/user/waybar.service; enabled)
 7#    Active: active (running) since Mon 2026-06-30 10:00:00 CST
 8#    Main PID: 1234 (waybar)
 9
10# 重啟
11systemctl --user restart waybar
12
13# 看最近的 log
14systemctl --user status waybar -n 20

如果這些工具不是 systemd unit（在 Hyprland config 裡用 exec-once 啟動的），就不能用 systemctl 管理。改用 pgrep 和 kill：

1pgrep waybar      # 查看是否在跑
2killall waybar    # 停止
3waybar &          # 背景啟動

即時資源監控

排查效能問題和記憶體耗盡時，需要看即時的系統資源使用情況。

htop：互動式 process 監控。按 M 可以按記憶體用量排序，按 P 按 CPU 排序。找到佔用異常的 process 後按 F9 可以直接 kill。

btop：功能更豐富的替代品，顯示 CPU、記憶體、磁碟、網路的即時使用情況，圖形化介面比 htop 直觀。

1# 安裝
2sudo pacman -S btop    # Arch
3sudo apt install btop  # Debian/Ubuntu
4
5# 執行
6btop

nvidia-smi：NVIDIA GPU 的專屬監控工具。顯示 GPU 使用率、記憶體、溫度、跑在上面的 process。

1# 一次性查看
2nvidia-smi
3
4# 持續監控（每 2 秒更新）
5nvidia-smi -l 2

常見 Log Pattern 速查

排查流程

這篇是 Hyprland 桌面的具體日誌工具；背後「先讀權威狀態、不靠肉眼猜」的通用診斷心法（每種問題的權威來源、四步流程），見 Linux 除錯與診斷：診斷心法。遇到桌面環境問題時的判讀順序：

1. 判斷影響範圍：只有一個視窗壞了、某個工具壞了、整個桌面壞了、還是系統完全不回應？影響範圍決定要看哪一層的 log。

2. 看 journalctl：journalctl -b -p err 先看本次開機有沒有錯誤等級的訊息。大部分 userspace 的問題（compositor crash、工具 crash）會出現在這裡。

3. 看 dmesg：如果 journalctl 沒有明顯線索、或症狀跟硬體有關（畫面凍結、USB 不回應），dmesg -T --level=err,warn 看 kernel 層有沒有硬體或 driver 錯誤。

4. 查特定工具的狀態：systemctl --user status <tool> 或 pgrep <tool> 確認工具是否還活著。如果死了，看它最後的 log 訊息。

5. 即時監控：如果問題是漸進式的（越來越慢、偶爾卡頓），開 btop 或 htop 觀察 CPU 和記憶體的即時趨勢，找出佔用異常的 process。

找到問題後的下一步

判讀完 log 確認問題類型後，行動路徑依問題性質分流：

• Config 錯誤：直接修 config，用 hyprctl reload 或重啟工具驗證。操作步驟見常見故障場景與恢復操作。
• 軟體 bug（segfault、特定操作觸發 crash）：到該軟體的 issue tracker（通常在 GitHub）搜尋錯誤訊息。Hyprland 的 issue tracker 在 github.com/hyprwm/Hyprland。回報 bug 時附上 hyprctl systeminfo 的輸出和相關的 journalctl log。
• GPU driver 問題：NVIDIA 用戶檢查是否有更新的 driver 版本（pacman -Syu nvidia）。AMD 用戶的 driver 跟 kernel 綁定，更新 kernel 就更新 driver（pacman -Syu linux）。
• 硬體故障（GPU has fallen off the bus 反覆出現）：軟體層面無法解決，需要檢查硬體（PCIe 插槽接觸、供電、溫度）。

X11（X Window System）是用了三十多年的傳統協議。成熟、穩定、所有工具都支援。設計上的根本問題是安全性——任何 X11 應用程式都能讀取其他視窗的內容和鍵盤輸入，這是協議層的限制，不是 bug。

Wayland 是設計來取代 X11 的新協議。每個應用程式只看得到自己的視窗、效能更好、對現代硬體的支援更完整。多數主流發行版已經把 Wayland 設為預設，但部分老舊應用程式和特殊需求（某些螢幕錄製、遠端桌面工具）的支援還在追趕中，這些情境會透過 XWayland（相容層）跑 X11 應用程式。

新的 tiling WM 主要基於 Wayland 開發，X11 上的老牌（i3, bspwm, dwm）仍然活躍但不再是未來方向。

主流 Tiling WM

i3（X11）/ sway（Wayland） 是社群最大、文件最齊全、行為最可預測的選擇。i3 跑在 X11 上，sway 是它的 Wayland 移植，配置格式幾乎相同。配置檔用自己的語法，直覺的 key = action 對應。

1# sway/config 片段
2set $mod Mod4
3bindsym $mod+h focus left
4bindsym $mod+j focus down
5bindsym $mod+k focus up
6bindsym $mod+l focus right
7bindsym $mod+Shift+h move left
8bindsym $mod+1 workspace number 1
9bindsym $mod+2 workspace number 2

穩定性是 i3/sway 最大的賣點——配置寫好之後很少因為更新而壞掉。適合想要可靠的平鋪工作流、不需要華麗視覺效果的人。

Hyprland（Wayland） 吸引的是在意桌面視覺品質的平鋪使用者——看 r/unixporn 的 Hyprland 截圖就知道，流暢的視窗切換動畫、圓角、視窗模糊、漸層邊框，這些傳統 tiling WM 社群視為不必要的裝飾，Hyprland 做成內建功能並且認真打磨。配置檔改完即時生效（hot reload），迭代調教的回饋循環很短。

這份視覺投入換來的 trade-off 是穩定性。開發節奏快意味著偶爾會有 breaking changes——某次更新後配置語法改了（2026 年 4 月的 Lua 遷移就是一例）、某個選項改名或移除。把它當主力桌面，要有「更新後可能要回來調配置」的心理準備。Hyprland 配置會詳細講它的設定。

bspwm（X11） 是純粹的 BSP 樹狀分割。它只做一件事：管理視窗的樹狀結構。所有操作透過 bspc 命令列工具驅動，快捷鍵綁定交給 sxhkd（一個獨立的快捷鍵 daemon）。UNIX 哲學——每個工具只做一件事，組合起來用。

dwm（X11） 極簡到配置要改 C 原始碼然後重新編譯。不是給「想要方便配置」的人用的，而是給「想要完全理解自己桌面每一行程式碼」的人用的。

拼裝式桌面的代價

Linux tiling WM 的桌面是你自己拼出來的：compositor（Hyprland/sway）負責視窗管理、狀態列（waybar）負責頂部資訊條、啟動器（rofi/wofi）負責 app 搜尋啟動、通知（mako/dunst）負責通知彈窗、鎖屏另外裝。每一塊是不同專案、不同作者。

好處是每一塊都可以換。壞處是當某件事壞了，你要自己判斷是哪一層的問題。藍牙選單不能點？可能是狀態列的 module 設定錯、可能是 blueman 沒跑、可能是 D-Bus session 有問題。完整桌面環境（KDE/GNOME）幫你整合測試過了，拼裝式桌面沒有這層保障。

多螢幕的處理

多螢幕是自動平鋪比較能展現價值的場景。每個螢幕是獨立的平鋪區域，視窗在哪個螢幕就在那個螢幕的範圍內平鋪。

快捷鍵跨螢幕操作是標配功能：把焦點跳到另一個螢幕、把當前視窗丟到另一個螢幕（丟過去後自動融入那邊的平鋪佈局）。三螢幕時這個便利性比單螢幕更明顯——純滑鼠拖視窗跨螢幕需要的移動距離很長。

工作區跟螢幕的綁定方式是各工具差異最大的地方。

macOS 的 Spaces 是綁定螢幕的——每個螢幕有自己獨立的一組 Spaces。yabai 沿用這個行為，切換工作區時只影響當前螢幕。AeroSpace 用自己的虛擬工作區繞過 macOS 原生 Spaces 的限制，多螢幕操作被普遍認為更穩定、更直覺。

Hyprland 的 workspace 可以動態指派到不同螢幕——workspace 3 現在在螢幕 A，你可以把它移到螢幕 B。這種模型彈性最大，但也需要清楚的心智模型來管理「哪個 workspace 在哪」。

熱插拔螢幕（接上、拔掉外接螢幕）是各工具的常見痛點。拔掉螢幕時，該螢幕上的視窗要搬到剩餘螢幕重新平鋪；插上螢幕時，佈局要擴展。多數工具有對應設定（記住螢幕配置、自動還原佈局），但體驗不見得完美，偶爾需要手動整理。

Dotfile 中的視窗管理配置

視窗管理是 dotfile 管理裡「桌面層」的核心。WM 配置檔決定了整個桌面的操作邏輯——快捷鍵怎麼綁、視窗間距多大、哪些 app 要浮動、工作區怎麼分配。

macOS 工具的配置檔通常是一個檔案：AeroSpace 的 ~/.aerospace.toml、yabai 的 ~/.yabairc + ~/.skhdrc、Amethyst 的 ~/.amethyst.yml。把這些檔案放進 dotfile repo，換 Mac 時就能還原整套視窗管理行為。

Linux tiling WM 的配置在 ~/.config/ 下，通常是一個資料夾：Hyprland 的 ~/.config/hypr/、sway 的 ~/.config/sway/、i3 的 ~/.config/i3/。除了 WM 本身，狀態列（waybar 的 ~/.config/waybar/）、啟動器（rofi 的 ~/.config/rofi/）、通知（mako 的 ~/.config/mako/）等周邊元件的配置也各自有檔案。一套完整的 Linux 平鋪桌面，dotfile repo 裡可能會有十幾個配置目錄——這也是為什麼 Linux 桌面客製化社群那麼依賴 dotfile 管理工具（見管理工具與目錄結構）。

跟螢幕硬體綁定的設定（螢幕解析度、縮放比、螢幕排列順序）通常也寫在 WM 配置裡。這部分在跨機器搬移 dotfile 時需要調整——同一份 Hyprland 配置裡的 monitor 設定，在筆電上是一個螢幕、在桌機上可能是三個。常見做法是把硬體相關設定拆到單獨檔案（如 monitors.lua），主配置用 require 引入，這樣跨機器時只需要替換這一個檔案。同步與環境重建會講跨機器搬移時怎麼處理這類硬體差異。

詞源

最被廣泛接受的說法是源自汽車改裝文化的 “rice burner” / “ricer”——原本指對（通常是日系的）平價車裝上浮誇外觀套件（大尾翼、炫光、貼紙），看起來拉風但實際性能沒提升。後來 Linux 社群借用這個概念：把桌面打扮得花俏好看，本質也是「外觀的炫技」。

也有人提出 “Race Inspired Cosmetic Enhancements” 的逆向縮寫，但普遍被認為是事後湊的解釋。

在 Linux 圈裡，rice 的原始貶意和種族色彩已經淡化，變成中性甚至帶自豪的自稱——r/unixporn 社群就是圍繞 ricing 成果的分享運轉的。

Rice 涵蓋的範圍

• 配色方案：Catppuccin、Tokyo Night、Gruvbox、Nord 等跨工具統一的色彩定義
• 狀態列：Waybar、Eww 的模組設計和 CSS 外觀
• 啟動器：Wofi、Rofi 的搜尋框外觀
• 通知：Mako、Dunst 的通知氣泡樣式
• 鎖屏：Hyprlock 的登入畫面設計
• 桌布：靜態桌布或動態桌布（Swww）
• 終端機配色：Alacritty / Kitty / Foot 的 ANSI 色碼
• 字型：Nerd Font 的 icon glyph

Caelestia 這類「desktop shell」專案把上述元件統一設計出貨，是「打包好的 rice」。手動逐一挑選和調教各元件是「DIY rice」。兩者的目標相同——視覺上協調、好看、符合個人美學。

完整的 rice 配置實務見桌面 Rice 設計。

Workspace 設定

Workspace 是平鋪式桌面的空間管理單位。Hyprland 的 workspace 是動態的——不需要預先定義多少個，按了不存在的 workspace 編號就會自動建立。

 1-- 把特定 workspace 綁定到特定螢幕
 2hl.config({
 3    workspace = {
 4        "1, monitor:DP-1, default:true",
 5        "2, monitor:DP-1",
 6        "3, monitor:DP-1",
 7        "7, monitor:HDMI-A-1, default:true",
 8        "8, monitor:HDMI-A-1",
 9        "9, monitor:HDMI-A-1",
10    },
11})

常見的使用模式：

• Workspace 1-3 放在主螢幕（寫程式用）
• Workspace 7-9 放在副螢幕（瀏覽器、通訊軟體、監控）
• 用鍵盤瞬間切換（SUPER + 數字鍵），比 alt-tab 在一堆視窗裡找快

Per-workspace layout 覆寫

1hl.config({
2    workspace = {
3        "1, layoutopt:orientation:left",     -- workspace 1 用左側 master
4        "2, layoutopt:orientation:top",      -- workspace 2 用頂部 master
5    },
6})

[VM 可測試] Workspace 切換、綁定邏輯、per-workspace layout。
[需實機測試] Workspace 綁定到特定實體螢幕的行為。

Window Rules

Window rules 讓特定應用程式在開啟時自動套用設定——指定 workspace、強制浮動、設定大小等。

 1hl.config({
 2    windowrule = {
 3        -- 特定 app 自動送到指定 workspace
 4        "workspace 8, class:^(firefox)$",
 5        "workspace 9, class:^(Slack)$",
 6
 7        -- 設定面板、對話框等維持浮動（不進平鋪）
 8        "float, class:^(pavucontrol)$",
 9        "float, class:^(nm-connection-editor)$",
10        "float, title:^(Open File)$",
11        "float, title:^(Save As)$",
12
13        -- Picture-in-picture 浮動 + 置頂 + 固定大小
14        "float, title:^(Picture-in-Picture)$",
15        "pin, title:^(Picture-in-Picture)$",
16        "size 480 270, title:^(Picture-in-Picture)$",
17        "move 100%-490 50, title:^(Picture-in-Picture)$",
18
19        -- 視窗透明度（active inactive）
20        "opacity 0.9, class:^(kitty)$",
21        "opacity 0.85 0.75, class:^(Code)$",
22
23        -- 防止 Electron app 自動最大化
24        "suppressevent maximize, class:.*",
25
26        -- XWayland video bridge（螢幕分享用）
27        "opacity 0.0 override, class:^(xwaylandvideobridge)$",
28        "noanim, class:^(xwaylandvideobridge)$",
29        "noinitialfocus, class:^(xwaylandvideobridge)$",
30        "maxsize 1 1, class:^(xwaylandvideobridge)$",
31        "noblur, class:^(xwaylandvideobridge)$",
32    },
33})

查詢應用程式的 class 和 title

1hyprctl clients          # 列出所有開啟的視窗（含 class、title、PID 等）
2hyprctl activewindow     # 當前焦點視窗的資訊

Window rules 用 regex 匹配 class 和 title。靜態 rules 匹配的是視窗開啟時的初始值（initialTitle / initialClass）。

Window rules 是讓平鋪式桌面「不只是把所有東西硬塞格子」的關鍵——識別哪些 app 適合浮動、哪些適合指定位置，需要累積使用經驗。

[VM 可測試] Window rules 邏輯、workspace 指派、float 規則。查 class/title 也在 VM 裡能做。

Layout 配置

Dwindle

每個新視窗把當前區域一分為二（螺旋式切分），適合不固定視窗數量的工作流：

1hl.config({
2    dwindle = {
3        pseudotile = true,       -- 允許 app 請求 pseudo-tiling（保留原始大小）
4        preserve_split = true,   -- 不自動改變分割方向
5        force_split = 2,         -- 0=跟隨滑鼠, 1=永遠左/上, 2=永遠右/下
6        smart_split = false,
7        smart_resizing = true,
8    },
9})

Master

一個主區域 + 其餘視窗堆疊在側邊，適合「一個主力視窗 + 多個參考視窗」的模式：

1hl.config({
2    master = {
3        new_on_top = false,       -- 新視窗放 master 還是 stack
4        orientation = "left",     -- master 區域位置：left / right / top / bottom / center
5        mfact = 0.55,             -- master 區域佔螢幕的比例
6    },
7})

在 general 裡設定預設 layout：

1hl.config({
2    general = {
3        layout = "dwindle",       -- 或 "master"
4    },
5})

[VM 可測試] Layout 切換和參數調整的行為邏輯。

外觀設定

 1hl.config({
 2    general = {
 3        gaps_in = 5,
 4        gaps_out = 10,
 5        border_size = 2,
 6        ["col.active_border"] = "rgba(89b4faee) rgba(cba6f7ee) 45deg",
 7        ["col.inactive_border"] = "rgba(313244aa)",
 8    },
 9    decoration = {
10        rounding = 8,
11
12        blur = {
13            enabled = true,
14            size = 5,             -- 模糊半徑（越高越模糊、越吃 GPU）
15            passes = 2,           -- 模糊次數（越多越平滑、越重）
16            vibrancy = 0.17,
17            noise = 0.02,
18            new_optimizations = true,
19        },
20
21        shadow = {
22            enabled = true,
23            range = 15,
24            render_power = 3,     -- 1-4，衰減曲線
25            color = "0xee1a1a2e",
26        },
27
28        dim_inactive = false,
29        dim_strength = 0.2,
30
31        active_opacity = 1.0,
32        inactive_opacity = 0.95,
33    },
34})

[需實機測試] blur 的效能影響和視覺品質——這是 Hyprland 最吃 GPU 的功能。VM 裡建議 blur = { enabled = false } 避免卡頓。shadow 和 rounding 在軟體渲染下可以動但會很慢。

動畫設定

 1-- 定義 bezier 曲線
 2hl.animation("bezier", "ease", 0.25, 0.1, 0.25, 1)
 3hl.animation("bezier", "overshot", 0.05, 0.9, 0.1, 1.05)
 4
 5-- Spring 物理動畫（較新的替代方案）
 6hl.animation("spring", "bouncy", 1, 8, 0)   -- damping, frequency, speed
 7
 8-- 套用動畫
 9hl.animation("animation", "windows", 1, 4, "ease", "slide")
10hl.animation("animation", "windowsOut", 1, 4, "ease", "popin 80%")
11hl.animation("animation", "fade", 1, 3, "ease")
12hl.animation("animation", "workspaces", 1, 4, "ease", "slide")
13
14-- 關閉特定動畫
15hl.animation("animation", "windowsMove", 0)

VM 裡跑 Hyprland 時，建議完全關閉動畫以維持可用的操作速度：

1hl.config({
2    animations = {
3        enabled = false,
4    },
5})

[需實機測試] 動畫流暢度是 Hyprland 的核心賣點，只有實機能評估。VM 裡的卡頓是 GPU 加速不足造成的，不代表 Hyprland 本身的效能。

Autostart

 1hl.config({
 2    exec_once = {
 3        -- 桌面元件
 4        "waybar",
 5        "mako",
 6        "hyprpaper",
 7
 8        -- 系統服務
 9        "/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1",
10        "wl-paste --type text --watch cliphist store",
11
12        -- Idle daemon（閒置鎖屏，鎖屏安全模型見 session-lock 卡）
13        "hypridle",
14    },
15})

exec_once 只在 Hyprland 啟動時跑一次（config reload 不會重複執行）。如果需要每次 reload 都重跑某個指令，用 exec（但多數情況不需要）。

Plugin 系統

Hyprland 用 hyprpm（Hyprland Plugin Manager）管理 plugin：

1hyprpm update                                              # 更新 plugin index
2hyprpm add https://github.com/hyprwm/hyprland-plugins     # 加入官方 plugin repo
3hyprpm enable hyprexpo                                     # 啟用 plugin
4hyprpm disable hyprexpo                                    # 停用 plugin
5hyprpm list                                                # 列出可用 plugin

Plugin 的配置寫在 hyprland.lua 裡，是 dotfile 的一部分。

[VM 可測試] 不依賴 GPU 的 plugin（hy3、hyprbars）。
[需實機測試] 視覺特效類 plugin（hyprexpo、hyprspace、hyprtrails）。

Dotfile 結構對應

Hyprland 的配置拆成多個 .lua 檔，全部放在同一個 stow package 裡。monitors.lua 是硬體相關的——跨機器搬移時可能要排除或用 template/local 機制處理（見跨平台共用一個 Repo）：

 1~/dotfiles/
 2└── hyprland/
 3    └── .config/
 4        └── hypr/
 5            ├── hyprland.lua       # 主入口（只有 require 行）
 6            ├── monitors.lua       # 硬體相關、可能排除或 template
 7            ├── keybinds.lua
 8            ├── rules.lua
 9            ├── autostart.lua
10            ├── appearance.lua
11            └── env.lua

穩定性與維護的務實面

Hyprland 的開發節奏快、功能更新激進。v0.55 的 Lua 遷移就是一個典型案例——配置格式整個換掉，舊的 .conf 只會再支援一到兩個版本。配置檔的語法和可用選項會隨版本變動。

應對策略：

• 更新前先看 Hyprland wiki 的 Configuring 頁面和 changelog
• dotfile repo 的 commit message 記錄「因應 Hyprland vX.Y 改了什麼設定」
• 如果用 Arch 的 rolling release，pacman -Syu 前先確認 Hyprland 是否有 breaking change（Arch 社群通常會在論壇預警）
• 官方提供遷移工具（如 hyprlang2lua），格式變更時優先使用

這是視窗管理與平鋪式工作流提過的代價——把日常桌面建立在高速移動的專案上，持續的配置維護是實際成本。

VM 與實機測試對照

第一步：分「連不到」還是「連得到但被拒」

錯誤訊息本身就能分層，不用猜：

• 訊息提到主機名解不出、連線逾時、retrieving file 失敗 → 連不到，往網路 / DNS / mirror 查。
• 訊息提到 database lock、signature、trust、conflicting、partial → 連得到、封包也拿到了，是套件管理器的狀態問題。

判準是問一句：「它到底有沒有成功連上 mirror？」有連上才談得到簽章、相依、db 狀態；連都沒連上，那些都還輪不到。剛裝好的最小系統最常見的是前者——網路設定還沒到位。

連不到那層：從實體介面往上查到域名

網路不通有好幾層，從最底層往上逐層確認，哪一層斷了一目了然。這條鏈跟最小安裝後的驗證裡的網路檢查同源，這裡聚焦在「抓套件失敗」這個症狀上：

1ip -brief a              # 1. 有沒有拿到 IP？介面 UP 且有位址
2ping -c1 8.8.8.8         # 2. IP 層對外通不通？（直接打 IP、跳過 DNS）
3getent hosts archlinux.org   # 3. 域名解得出來嗎？
4timedatectl              # 4. 時間對嗎？（影響下一層的簽章驗證）

第 2 步通、第 3 步不通 = DNS 問題，這是最小安裝最典型的落點：IP 層明明通（ping 8.8.8.8 有回應），但域名解不出來，因為 /etc/resolv.conf 還沒設 nameserver。這時 pacman 會卡在解析 mirror 主機名。修法是給系統一個 resolver——臨時可直接寫 /etc/resolv.conf（nameserver 1.1.1.1）。先看它是什麼（ls -l /etc/resolv.conf）：啟用了 systemd-resolved 或 NetworkManager 的系統上它是那些服務管理的 symlink，手寫會被覆蓋，治本要透過該網路管理服務設定 DNS；裸 Arch 最小安裝若沒啟用這些服務，它通常就是一個普通檔案，手寫即持久生效。

mirror 逾時 / 抓不到：DNS 通了、但某個 mirror 慢或掛了。換 /etc/pacman.d/mirrorlist 到地理近且快的鏡像（實測不同 mirror 速度可差數倍）。這也接回安裝選項判讀裡選 mirror 的決策——裝機當下選錯 mirror，這裡就會慢。

連得到但被拒那層：pacman 自己的狀態

連上 mirror、封包也拿到了卻失敗，問題在 pacman 的本地狀態或簽章驗證。這幾種各有明確徵兆與修法：

database lock：上次沒清乾淨的殘留

error: failed to init transaction (unable to lock database)。pacman 用 /var/lib/pacman/db.lck 這個鎖檔保證同時只有一個 pacman 在動資料庫；上次 pacman 被中斷（斷電、Ctrl+C、當掉）沒清掉鎖檔就會殘留。先確認真的沒有 pacman 在跑（pgrep -x pacman），確認沒有再刪鎖檔：

1pgrep -x pacman && echo "有 pacman 在跑、別刪" || sudo rm /var/lib/pacman/db.lck

先查再刪這個順序重要——盲刪鎖檔時如果真的有另一個 pacman 在跑，兩個同時寫資料庫會弄壞它。

簽章 / keyring 過期：十之八九是時間不對

invalid or corrupted package (PGP signature) 或 signature is unknown trust。pacman 驗證每個套件的 GPG 簽章，驗證失敗最常見的根因是系統時間不對——這正是第一步要 timedatectl 的原因。時間差太多（新裝的 VM、主機板電池沒電的老機器）會讓「簽章的有效期」判斷錯誤，明明有效的簽章被判過期。先校時：

1sudo timedatectl set-ntp true     # 開 NTP 自動校時（SSH 進最小系統無 polkit 互動代理、裸跑會被拒，要 sudo）

時間對了還失敗，才是 keyring 本身的問題（archlinux-keyring 太舊）：sudo pacman -Sy archlinux-keyring 更新 keyring，必要時 sudo pacman-key --refresh-keys。順序是先校時再動 keyring，因為時間不對時連 keyring 都更新不了。

partial upgrade：只同步不升級造成的相依斷裂

conflicting dependencies 或裝完某個套件後系統行為異常。根因是在 rolling 發行版上只做了 pacman -Sy（同步資料庫）就裝新套件，卻沒 -u（升級既有套件）——新套件依賴新版函式庫，但系統還是舊的，相依對不上。Arch 只支援 full upgrade：一律 pacman -Syu，永遠不要單獨 -Sy 之後裝東西。這條規則救掉這一整類故障。

stale db 404：裝機當下的資料庫已經過期

error: failed retrieving file '...' 404，而且換好幾個 mirror 都一樣。這是 rolling 發行版特有的時序陷阱：Arch 的 mirror 不保留舊版檔案，你裝機時 ISO 內建的套件資料庫指向的檔名，可能幾天內就被輪替掉了——資料庫說有這個檔、mirror 上已經沒有。修法跟上一條同源：pacman -Syu 先把資料庫同步到最新，檔名對上了就抓得到。這也是為什麼「一律 -Syu」是 Arch 的鐵律，而不只是建議。

判讀總表

下一步

• 這幾步用到的網路驗證，完整版在最小安裝後的工具驗證與補足。
• 裝機時選 mirror / locale / 時區的決策，見Linux 安裝選項判讀。
• 跨發行版時「這個套件名 / 這個旗標在別的發行版叫什麼」的差異判讀，見平台與發行版差異的判讀地圖。
• 套件抓下來了、但 bootstrap 腳本本身失敗要 debug，見可除錯的 bootstrap。
• 系統跑起來後才出的套件問題（AUR 建置失敗、-bin 包 soname 斷裂等），屬除錯範疇，見Linux 除錯與診斷。

底層的心法（讀權威狀態、不靠肉眼）見 診斷心法，這篇是它在「程序 / 服務 / 狀態」這一類的具體招式。

程式活著沒：比對正確的行程名

判斷一個程式在不在，行程表是權威來源，pgrep / ps 是對的工具，但成敗在於比對正確的行程名（comm，行程表裡記的執行檔短名，可從 /proc/<pid>/comm 看）。一個實際的坑：某個桌面 shell（畫桌面 UI 的圖形程式，不是 bash/zsh 那種命令列 shell）的可執行檔叫 quickshell，但透過名為 qs 的 symlink 啟動時，它在行程表裡的 comm 是 qs。這時 pgrep quickshell 找不到，很容易誤判成程式掛了、甚至誤觸「重啟」而引發更大的問題，實際上它以 qs 這個名字好好跑著。

可靠的做法：

• 先確認實際的 comm 名：ps -eo pid,comm | grep -i <關鍵字>，或看你啟動它的實際指令。
• 用精確比對：pgrep -x <comm>（-x 要求完全相符），或 pgrep -af <pattern> 連完整命令列一起比對，避免被 symlink 名 / 縮寫名騙。
• 另一個 comm 的坑：kernel 把 comm 截在 15 字元（TASK_COMM_LEN），名字超過 15 字的程式用 pgrep -x <完整長名> 反而 miss——這時改用 pgrep -af <pattern> 比對完整命令列。
• 別用一個「你以為的名字」掃過去就下生死結論——行程表沒騙你，是查詢條件寫錯。

進程活著 ≠ 內部子系統活著

比對到了正確的 comm、pgrep 也有輸出，只證明「這個進程存在」，不證明「它內部在正常運作」。有一類故障是進程好端端活著（pgrep 找得到、STAT 是正常的 S、在 poll 等事件、CPU 不高），但它內部某個子系統已經 wedged——例如一個圖形 shell 的 QML scene 因為上游錯誤（渲染 pipeline 建失敗之類）某個物件沒建起來變 null，於是負責互動的模組全部失效。表現是 bar 還畫得出來、卻點不動，keybind 叫不出東西，但焦點視窗打字正常。這時 pgrep 會騙你說「在跑」。

這種情況權威來源不是行程表，是程式自己的 log，而且這種 log 常常不在 journalctl、也不在你猜的路徑，要用該程式專屬的 log 指令（例如某桌面 shell 的 <shell> -l）。log 裡的 TypeError: Cannot read property 'X' of null 這類訊息，才是「進程活著但子系統死了」的定案證據。另一個更精準的活性探針是程式的 IPC 回不回真實狀態：正常時查詢會回傳資料、子系統死掉時回空——這比「進程在不在」可靠得多。判「進程活著到底有沒有在運作」時，讀它自己的 log 與 IPC，不是看 pgrep 有沒有輸出。桌面 shell 的具體案例與恢復（讀 caelestia shell -l 抓到 null 根因、重啟重建 scene）見 常見故障場景與恢復操作 的「畫得出來但互動死掉」場景。

服務由誰提供：問註冊表

「某個系統服務現在由哪個程式在提供」，權威來源是服務註冊，不是畫面。桌面服務多半註冊在 D-Bus（Linux 桌面的行程間訊息匯流排）上：一個服務用一個名字掛在上面，而同一個名字同一時間只能被一個行程擁有。以桌面通知為例，org.freedesktop.Notifications 這個 D-Bus 名同一時間只有一個擁有者——兩個通知 daemon（例如 mako 跟某個桌面 shell 內建的通知服務）不能共存，誰先註冊誰佔著，後者只能等前者退出。

想知道現在是誰接管，查註冊表而不是送一則通知看畫面：

1# 查 org.freedesktop.Notifications 目前被哪個連線擁有
2owner=$(busctl --user call org.freedesktop.DBus /org/freedesktop/DBus \
3  org.freedesktop.DBus GetNameOwner s org.freedesktop.Notifications | awk '{print $2}' | tr -d '"')
4# 把那個連線換算成 PID，再看行程名
5pid=$(busctl --user call org.freedesktop.DBus /org/freedesktop/DBus \
6  org.freedesktop.DBus GetConnectionUnixProcessID s "$owner" | awk '{print $2}')
7ps -o comm= -p "$pid"

停掉舊 daemon 前擁有者是舊的、停掉後換成新的，就確認接管成功。這比「送通知看畫面有沒有跳」可靠——畫面沒跳可能是勿擾模式吃掉、可能根本沒送出，畫面反應不等於服務歸屬。切換兩個搶同一服務名的 daemon 時，這也解釋了為什麼「新的裝了卻沒作用」：舊的還佔著名字，新的靜默註冊失敗（通常只在它的 log 留一行 warning），得先停掉舊的。

桌面 session 有沒有被鎖：認清是哪一層的鎖

判斷一個圖形 session 有沒有被鎖，最容易被畫面帶偏，因為「畫面上有密碼框」很有說服力、卻不等於 session 真的被鎖（現代桌面 shell 的儀表板常內嵌鎖屏樣式的 widget）。而且鎖有不同層，查錯層會得到誤導的答案。

關鍵是分清兩種鎖：

• logind 層的鎖：systemd 登入管理的 session 鎖，權威狀態是 loginctl show-session <id> -p LockedHint。
• Wayland 合成器層的鎖：走 ext-session-lock 協議、由合成器（compositor，Wayland 下負責把各視窗合成到螢幕、管輸入輸出的核心程式，約當 X11 時代的視窗管理器加顯示伺服器；Hyprland、Sway 等都是）管的鎖，跟 logind 是獨立機制。這種鎖 loginctl 的 LockedHint 查不到——不是沒鎖，是查錯層。（用 GNOME / KDE 的鎖屏走的機制不同，以下的 ext-session-lock 判法與復原針對 wlroots 系的 Wayland 合成器。）

所以「loginctl 沒有 LockedHint、pgrep 找不到獨立鎖屏程式」不足以斷定「沒鎖」：合成器層的鎖不歸 logind、而鎖屏畫面可能由 shell 主程式在自己行程內畫（沒有獨立可執行檔可抓）。這種情況真正的權威來源是那個 shell 自己的 log（有沒有載入鎖屏模組、idle 計時器有沒有觸發鎖定），或直接看 compositor 的 session-lock 狀態。判鎖看合成器 / shell 的 log，不是 loginctl、更不是畫面有沒有密碼框。

鎖屏程式死掉造成的死局與復原

ext-session-lock 有一個安全設計：持鎖的鎖屏程式若在鎖定狀態下崩潰 / 被中止，compositor 會保持鎖定、不會因為鎖屏程式沒了就解鎖（否則殺掉鎖屏程式就成了繞過鎖的漏洞）。表現是畫面卡在「鎖屏程式已死」的安全提示。復原要從另一個 VT 或 SSH 用 hyprctl keyword misc:allow_session_lock_restore 1 允許新鎖屏 client 接管、再 hyprctl dispatch exec hyprlock 起一個接管後輸密碼解鎖。完整機制、兩層鎖的關係、各 compositor 的差異，見 Wayland Session Lock 卡。

診斷紀律：測鎖屏、或 pkill 一個持鎖的鎖屏程式時，要預期它把 session 卡在鎖定——這是協議的安全設計，不是 bug。 自動化 / 無人值守流程尤其要避免在持鎖狀態下殺鎖屏程式。

終端機多工器的 session 還在不在

用 zellij / tmux 這類多工器跑遠端長任務時，判斷「重連後那個 session 還在不在」的權威來源是多工器自己的 session 列表，不是「我 SSH 斷了所以應該還在吧」的假設。zellij ls（或 tmux ls）會列出 session 與狀態：多工器是常駐在遠端的程序，SSH 斷不影響它，所以只要那台機器沒重開，attach 就能接回去；但如果機器重開過、或那個 session 因為資源不足（例如磁碟滿觸發的連鎖）被殺，列表會顯示它已 EXITED / 不存在，這種接不回去。

這裡有個順序上的紀律：當一個 session 可能已經死掉、而它裡面跑的任務有你在意的產出時，先確認產出有沒有被安全保存，再處理 session。 例如任務是在改 git repo，先 git -C <repo> status 跟 git log @{u}..（本地有、遠端沒有的 commit）確認有沒有沒推送的東西、把該推的推掉，再去 zellij delete 清死 session。搞反順序、先清了 session，可能連帶失去唯一還記得那些改動的地方。權威狀態（git 的推送狀態、多工器的 session 列表）先讀清楚，再動手。

判讀路由

• 判程式活著 → pgrep -x <正確 comm> / pgrep -af <pattern>，先確認實際 comm 名，別用猜的名字。
• 判進程活著但「有沒有在運作」→ 讀程式自己的 log（可能要用它專屬的 log 指令、不在 journalctl）+ 它的 IPC 回不回真實狀態，不是看 pgrep 有輸出就當正常。
• 判服務歸誰 → busctl 查 D-Bus name 擁有者 → 換算 PID → comm，不看畫面反應。
• 判 session 鎖沒鎖 → 分清 logind 層（loginctl LockedHint）vs 合成器層（ext-session-lock，看 compositor / shell log），不看畫面有沒有密碼框。
• 鎖屏程式死掉卡住 → allow_session_lock_restore + 重起鎖屏程式接管解鎖。
• 判多工器 session 存活 → zellij ls / tmux ls；可能已死且有在意的產出時，先確認產出已保存 / 已推送再清 session。

判不準時，診斷心法 的四步（描述症狀、定位權威來源、用對工具讀、矛盾時信權威）是通用的回退。

dotfile 管理解決的核心問題是環境可重現性。一台新機器、一次重灌、一個 VM，都應該能用一份 Git repo 還原成你熟悉的工作環境。不做管理的代價是：每次換機器都在重新手動設定，每次都少記一兩個東西，每次都花一兩天才回到順手的狀態。

和其他系列的關係

Infra 教「組織的地基怎麼用 code 管理」，Dotfile 教「個人的工作桌面怎麼用 code 管理」。模組九把兩者接起來——當個人 dotfile 的思想擴展到團隊，就是 devcontainer 和標準化開發環境。

地基：機器初始化

編號模組都假設你已經有一台裝好 Linux、工具齊全、能從外部連入的機器。Linux 安裝與機器初始化 補的是那段被預設跳過的地基——OS 安裝選項怎麼判讀、最小系統缺哪些必要工具、怎麼連進去跑 bootstrap（含還沒有 SSH key 的情況），以及怎麼讓安裝腳本在失敗時可診斷。只要你換到全新環境（開 VM、租雲端主機、拿到空機器），就會先撞上這層。內容來自一次完整的 VM 實測，蒸餾成不綁特定發行版的判讀與決策。

教學模組

模組編號反映學習路徑：先理解為什麼、再學怎麼管理、然後逐層處理 shell/終端機/視窗管理/視覺客製化，最後談維護排錯、同步可攜性和團隊化。模組四到七是 Linux 桌面環境的深度實作，之後會搭配 VM 專案做 hands-on 實測。

VM 實測專案

模組四到七的 Linux 桌面配置會搭配一個獨立的 VM 專案做 hands-on 實測（類似 Monitoring 系列搭配 monitor 專案的關係）。教材負責概念與配置邏輯的說明，VM 專案負責實際安裝、調教、截圖驗證。VM 專案會在教材完成後另外建立。

Wayland 是協議，不是軟體

一個常見的誤解是把 Wayland 當成「一個程式」。Wayland 是一份協議規格（protocol specification），描述了 client（應用程式）和 compositor（負責合成畫面的東西）之間怎麼傳遞 buffer、怎麼處理輸入事件。

每個 Wayland compositor 同時扮演三個角色：display server（管理顯示輸出）、window manager（管理視窗排列）、compositor（合成最終畫面）。X11 的世界裡這三個角色是分開的，Wayland 把它們統一成一個程式。這個「三合一」定位的濃縮版與它在故障排除中的責任邊界，見 Compositor 術語卡。

「Hyprland 是 Wayland compositor」這個說法的意思是：它不只是一個視窗管理器，它同時是整個圖形系統的核心。

X11 vs Wayland 架構差異

X11 的三角架構（1984 年設計）

1應用程式 ──→ X Server（中央仲介）──→ Compositor ──→ 螢幕
2             ↑                         ↑
3             └── 輸入事件 ──────────────┘

X Server 是一個龐大的中央仲介，負責接收所有應用程式的繪圖指令、管理輸入事件、再把畫面交給 compositor 做最終合成。Compositing 是後來才加上去的（Compiz、picom 這些都是外掛的 compositor），不是 X11 原始設計的一部分。

Wayland 的直接模型（2008 年設計）

1應用程式 ──→ Compositor（= display server + window manager）──→ 螢幕
2             ↑
3             └── 輸入事件

應用程式用 OpenGL/Vulkan 自己渲染畫面到 buffer，然後把 buffer 直接交給 compositor。沒有中間人。compositor 收到所有 client 的 buffer 後合成最終畫面輸出到螢幕。

這個架構上的差異帶來三個實際影響：效能、安全、screen tearing。

安全性

X11 的安全模型有一個根本性的設計缺陷：任何連到同一個 X Server 的 client，都能監聽其他 client 的鍵盤輸入、擷取其他視窗的畫面、甚至注入假的輸入事件。這代表一個惡意程式可以輕易做到 keylogging——記錄你在其他視窗打的所有字，包括密碼。

Wayland 從協議層就隔離了 client 之間的存取。每個應用程式只看得到自己的 buffer，無法存取其他視窗的內容或輸入。要做 screen capture 或 screen sharing，必須透過 xdg-desktop-portal 這個受控的中介機制，使用者會看到明確的授權提示。

對 tiling WM 的使用者來說，這個安全差異特別有意義：平鋪式桌面通常同時開大量終端機視窗（有些跑 SSH、有些在 sudo 操作），X11 下任何一個視窗裡的惡意程式都能讀到其他視窗的鍵盤輸入。Wayland 阻斷了這條攻擊路徑。

效能與 Screen Tearing

X11 的渲染路徑有多餘的記憶體複製——應用程式把繪圖指令送給 X Server，X Server 渲染後再交給 compositor，compositor 再合成。Wayland 省掉了中間那一步：應用程式直接渲染到 buffer、直接交給 compositor，記憶體複製更少。

Screen tearing（畫面撕裂）在 X11 上是長年的老問題——需要 compositor + vsync 的各種 workaround。Wayland 在協議層就處理了 frame presentation 的時機，compositor 控制什麼時候把合成好的畫面送到螢幕，原生消除 tearing。這也是為什麼 Hyprland 的動畫能跑得流暢——直接 rendering + 原生 vsync 的組合，在 X11 上需要大量額外配置才能接近的效果。

XWayland：X11 相容層

很多應用程式仍然只支援 X11 協議。XWayland 是一個 X11 server，但它本身作為一個 Wayland client 運行——X11 應用程式連到 XWayland，以為自己在跟正常的 X Server 溝通；XWayland 把 X11 協議翻譯成 Wayland 協議，把 buffer 交給 compositor。

多數 Wayland compositor（包括 Hyprland）預設啟用 XWayland，X11 應用程式不需要任何設定就能運行。

需要 XWayland 的常見應用

• 舊版 Electron 應用（新版可用 --ozone-platform=wayland 旗標切換到 Wayland 原生）
• Java 應用程式（NetBeans 等）
• 舊的 GTK2 應用程式
• 部分 Wine/Proton 遊戲（但 XWayland 下的遊戲效能已經相當好）
• 未啟用 PGTK 的舊版 Emacs build（Emacs 29+ 的 PGTK 後端已原生支援 Wayland）

XWayland 的已知問題

最大的實務痛點是 HiDPI 非整數縮放。在 150%、125% 等非整數 scale 下，XWayland 應用程式可能出現模糊渲染，因為 XWayland 不支援 fractional scaling 協議。整數縮放（100%、200%）則沒有問題。

關鍵 Wayland 協議

wlr-layer-shell

Layer-shell 定義了 client 可以在螢幕的哪個「層」上建立畫面——background（最底）、bottom、top、overlay（最頂）。Status bar（waybar）、notification daemon（mako）、launcher（wofi）、wallpaper（hyprpaper）、lock screen（hyprlock）都透過 layer-shell 來佔據螢幕空間。

沒有 layer-shell 支援的 compositor，這些桌面元件就無法運作。這也是為什麼桌面 Rice 設計的所有工具都只能在支援 layer-shell 的 Wayland compositor 上跑——它是可組裝式桌面的基礎設施。

xdg-desktop-portal

Portal 是一個 D-Bus 介面，讓被隔離的 Wayland 應用程式可以請求特權操作：screen sharing、檔案對話框、螢幕截圖。每個 compositor 提供自己的 portal backend：

• Hyprland：xdg-desktop-portal-hyprland
• GNOME：xdg-desktop-portal-gnome
• KDE：xdg-desktop-portal-kde
• Sway/wlroots 系：xdg-desktop-portal-wlr

Screen sharing 的完整鏈路是：PipeWire + xdg-desktop-portal-hyprland。OBS 的 PipeWire source、瀏覽器的畫面分享，都走這條路。

wlroots 與 Hyprland 的關係

wlroots 是一個模組化的 C library，提供 Wayland compositor 的共用基礎建設——輸入處理、輸出管理、協議實作。Sway、river、wayfire 這些 compositor 都基於 wlroots 開發，共享同一套底層程式碼。

Hyprland 最初也基於 wlroots，但後來 fork 出去自己維護底層。這讓 Hyprland 可以更快地加入新功能（動畫、模糊、漸層邊框），不需要等 wlroots 上游審核。代價是 Hyprland 的更新不再跟 wlroots 生態同步，偶爾會有相容性差異。

2026 年的 Wayland 採用現況

Wayland 在 2026 年已經從「取代 X11 的方向」變成「Linux 桌面的預設」：

X11 上的老牌 tiling WM（i3、bspwm、dwm）仍然活躍，但不再是新專案的主流方向。新的 tiling WM 幾乎都選擇 Wayland 作為基礎。

X11 仍有優勢的場景

Wayland 並非在所有面向都超越 X11：

• SSH X forwarding：X11 原生支援透過網路轉送 GUI 視窗（ssh -X）。Wayland 沒有對等機制，替代方案是 waypipe，但不是 drop-in replacement
• 跨 compositor 的 GUI 自動化：xdotool、wmctrl 在 X11 上可以操控任何 WM 的視窗。Wayland 沒有跨 compositor 的通用對應方案——每個 compositor 提供自己的 IPC 工具。不過 Hyprland 的 hyprctl 在 Hyprland 環境內提供了比 xdotool 更豐富的能力：socket-based IPC、JSON 格式查詢所有視窗和工作區狀態、即時 dispatch 動作、event 監控（hyprctl socket2）。瓶頸在「跨 compositor 通用」，不在單一 compositor 內的功能深度
• VNC / 遠端桌面：X11 的網路透明性讓遠端桌面相對簡單。Wayland 需要 PipeWire + portal，設定複雜度更高
• Color management：專業色彩工作流（ICC profile 管理）在部分 Wayland compositor 上仍需手動配置

這些場景如果是你的核心需求，目前 X11（或 X11-based 的 i3/sway 的 X11 版本）可能仍是更務實的選擇。

為什麼 Tiling WM 使用者該關心 Wayland

平鋪式桌面是「自己從元件組裝桌面」的工作流。Wayland 的幾個特性讓這件事變得更好：

layer-shell 給了 status bar、launcher、notification daemon 一個標準化的方式來佔據螢幕空間，不再需要各種 hack 讓這些元件「浮在視窗上面又不被平鋪規則管到」。

安全隔離在多終端機場景特別有價值——平鋪式桌面通常同時開著 SSH session、密碼管理器、sudo 操作，Wayland 確保任何一個視窗裡的程式都無法偷看其他視窗的鍵盤輸入。

直接 rendering 讓 Hyprland 能做到流暢的視窗動畫和即時模糊，這在 X11 上需要大量額外的 compositor 配置（picom + 各種 backend 選擇 + vsync 調校）才能接近。

從實務角度看：2026 年開始接觸 Linux tiling WM，選 Wayland-based 的工具（Hyprland、Sway）是順流而行。X11 不會立刻消失，但新功能、新工具、社群活力都在 Wayland 這一邊。

理解這個框架後，監控就不是「裝一套很重的東西」，而是分層選擇：從 systemd 內建的失敗鉤子（不裝任何額外服務），到推播管道，到「整台機器死掉」的體外心跳，到完整的指標儀表板。多數人只需要前一兩層。

你現在手動在做的事（要被取代的基線）

在自動化之前，先認清手動版本——這也是所有告警底層讀的同一個權威來源：

1systemctl --failed          # 現在有哪些 unit 處於 failed（開機後系統怪怪的先掃這個）
2systemctl is-failed <unit>  # 單一 unit 明確判失敗（比 is-active 直接）
3journalctl -u <unit> -f     # 即時跟一個 unit 的 log

systemctl --failed 就是「服務死活」的權威清單。手動版的問題不是不準，是你得記得去看。下面每一層都是把「記得去看」換成「壞了它來找你」。

第一層：systemd 原生 OnFailure 鉤子（不裝額外服務）

systemd 每個 unit 進入 failed 狀態時，可以自動觸發另一個 unit。這是最正統、零額外依賴的做法——告警邏輯就寫成一個普通的 systemd service。它由三塊組成：一個負責送通知的處理器 unit、一個實際送出的腳本、以及在你要監控的 unit 上掛一行 OnFailure=。

通知處理器是一個 template unit（@ 表示可帶參數），參數 %i 會是失敗的那個 unit 名：