日常指令的現代替代品

• 現代 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 與套件清單。

連線層：從 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 操控圖形桌面等連線本身的問題：除錯與診斷：遠端連線與終端機問題。
• 機器完全沒回應、域名解析不了、虛擬機起不來：機器連不到或起不來。
• 把遠端機器設成無人值守、離開後自己跑完長任務送回成果：讓機器跑無人值守的長任務。

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

文章

相關

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

這篇用「圖形檔案管理員」當具體案例，但判讀方式適用於任何你想加進最小環境的桌面 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 環境設定與測試矩陣。

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

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

以搜尋為例：多數教材教 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 安裝與機器初始化：讓機器跑無人值守的長任務。

讀法

效能工具要從問題節點進入。團隊如果缺 workload model，先讀 9.2 Workload Modeling；如果缺 saturation 邊界，先讀 9.4 Saturation Discovery；如果缺 production 驗證，先讀 9.10 Production-Side 驗證。

工具頁的任務是承接這些問題節點。k6、JMeter、Gatling、Locust 與 Vegeta 都能產生負載，但它們在腳本語言、protocol 覆蓋、分散式執行、CI integration、報表與團隊學習成本上不同；production replay、profiling 與 cost analysis 工具則承擔不同的證據責任。

教學順序同步

效能與容量工具頁的教學順序是先建立 load test，再進入 replay / mirroring、profiling、optimization 與 FinOps。這個順序對齊 checkout E7：讀者先理解 workload model、saturation evidence 與 capacity gate，再比較 production traffic evidence、profile evidence、rightsizing 建議與成本 owner 如何形成改善閉環。

T1 工具頁

這批工具頁已完成 load test、production traffic replay、continuous profiling 與 capacity / cost analysis 的主要分流。k6 承接 scriptable scenario，JMeter 承接企業測試資產，Gatling 承接 JVM simulation，Locust 承接 Python custom behavior，Vegeta 承接快速 HTTP probe；GoReplay、Service Mesh Mirroring 與 AWS VPC Traffic Mirroring 承接不同層級的 production traffic evidence；Datadog Continuous Profiler、Pyroscope 與 Parca 承接不同操作模型的 profile evidence；Akamas、Vantage、CloudHealth 與 AWS Cost Explorer 承接 cost visibility、optimization 與 FinOps governance。

內容覆蓋進度

每個工具頁下會擴充兩類文章：deep article（工具自身的配置、故障、容量、走 6-section 模板）跟 migration playbook（跨工具遷移流程、走 6-type 結構）。「← X」代表從 X 遷入。

其他 T1 工具（JMeter / Gatling / Locust / Vegeta / GoReplay / Service Mesh Mirroring / AWS VPC Traffic Mirroring / Pyroscope / Parca / Akamas / Vantage / CloudHealth / AWS Cost Explorer）尚未開始。跟 06 vendors 共用部分工具（k6 / JMeter / Gatling / Locust），未來寫 deep article 時需明確區分「驗證流程的工具鏈」（06）跟「效能工程的工具鏈」（09）的角度。對應的 backlog 議題見上方「T1 工具頁」段每個工具頁要回答的核心責任、跟各工具 _index.md 的「預計實作話題」段。

後續候選

Load test 工具頁要保留 workload model 語言。JMeter 適合 protocol 覆蓋與 GUI 驅動團隊，Gatling 適合程式化 scenario 與 JVM 生態，Locust 適合 Python 團隊，Vegeta 適合簡單 HTTP 壓測與 CLI workflow。

Production replay 工具頁要保留安全與副作用邊界。Replay production traffic 會碰到 PII、credential、payment callback、idempotency 與下游配額，因此文章要先定義遮罩、隔離、rate limit 與 stop condition。

Profiling 工具頁要保留長期成本。Continuous profiling 能降低退化定位時間，但會增加採樣成本、儲存成本、敏感資訊治理、symbolization 與 baseline 維護責任。

Capacity / cost analysis 工具頁要保留 owner 與行動閉環。成本報表只有在 tag、label、cost center、service owner、release marker 與 action workflow 對齊後，才會變成容量規劃與成本改善的工程證據。

主流覆蓋檢查的重點是分開 scenario load、quick probe、managed runner、traffic replay、profiling、FinOps 與 component benchmark。k6 / Gatling / Locust 解 scenario；Vegeta / wrk / hey 解 quick HTTP probe；Grafana k6 Cloud / AWS Distributed Load Testing / BlazeMeter 解 managed runner；Pyroscope / Parca / Datadog / cloud profiler 解 profiling；Kubecost / CloudZero / CAST AI 解 workload cost。

工具頁標準章節

跨 vendor 議題對照

本模組 15 個 vendor 跨 5 個 sub-category（load test / production replay / continuous profiling / optimization / FinOps）、解不同效能與容量工程問題、不是同類選一。

對照表的用途有三：

• 對齊 sub-category 跟問題節點：缺 saturation → load test；缺 production gap → replay；缺 瓶頸定位 → profiler；缺 capacity / cost 閉環 → optimizer + FinOps
• 評估 production 風險：load test 安全、replay / mirror 要明示 side effect 邊界、profiler 要看採樣 overhead、FinOps reporting 無風險
• 對齊 owner：load test 多 Engineering / QA、replay 多 SRE + Security、optimization + FinOps 跨團隊

下面 5 段把對照表的 sub-category 展開、每段帶 vendor 選型判讀。

Load test（k6 / JMeter / Gatling / Locust / Vegeta）

Load test 是 09 模組的主要 saturation 探測工具、跟 06 reliability load test 章節 同 vendor 但角度不同 — 06 看 CI gate / regression evidence、09 看 capacity planning / saturation discovery / peak event readiness。

選型判讀：CI-first JS → k6；JVM + 複雜 scenario → Gatling；既有 .jmx 資產 → JMeter；Python custom behavior → Locust；快速 HTTP probe / fixed rate → Vegeta（單一 HTTP attack 模式、不適合多 step scenario）。

Production replay（GoReplay / Service Mesh Mirroring / AWS VPC Traffic Mirroring）

Production replay 把實際流量重播到 shadow target、補 load test 的「人工 scenario 跟真實流量差距」缺口。GoReplay 應用層 HTTP traffic capture + replay；Service Mesh Mirroring 用 Envoy / Istio proxy mirror、適合 K8s 內部；AWS VPC Traffic Mirroring L4 封包鏡像、適合非 HTTP / 低侵入。

選型判讀：HTTP application 層 → GoReplay；K8s 內 service mesh → Service Mesh Mirroring；非 HTTP / 跨 VPC / 低侵入 → AWS VPC。共同議題：PII 遮罩、idempotency boundary、downstream 配額 — 不可省。

Continuous profiling（Datadog Continuous Profiler / Pyroscope / Parca）

Continuous profiling 在 production 持續採樣、退化時可 profile diff 找瓶頸。Datadog Continuous Profiler SaaS APM 整合、deploy marker 自動關聯；Pyroscope OSS / Grafana 生態、可自管或 Grafana Cloud；Parca eBPF-based、infrastructure-wide profile（不需 application instrumentation）。

選型判讀：已用 Datadog APM → Datadog Profiler；Grafana 生態 / OSS → Pyroscope；不想 instrument application + eBPF 友善 → Parca。共同議題：採樣 overhead（CPU / memory）、symbolization、storage cost、敏感資訊。

Optimization（Akamas）

Optimization 把 workload + SLO + cost 放進同一閉環、產出 configuration recommendation。Akamas 是 09 模組唯一 optimizer vendor、適合已有可量測 workload 跟成本壓力的服務。

選型判讀：Kubernetes rightsizing + runtime tuning + cost target → Akamas；純 FinOps reporting 不夠（要主動建議）→ Akamas。Akamas 不替代 FinOps tool — Vantage / CloudHealth 看歷史成本、Akamas 提產出未來 recommendation。

FinOps（Vantage / CloudHealth / AWS Cost Explorer）

FinOps 提供 cost visibility + forecast + allocation。Vantage Kubernetes cost + forecast 友善的 startup-friendly 平台；CloudHealth enterprise FinOps governance + policy + chargeback；AWS Cost Explorer AWS-native cost analysis baseline（免費、限 AWS）。

選型判讀：純 AWS 啟動 → Cost Explorer；多雲 + startup / mid-size → Vantage；enterprise + 多 BU chargeback → CloudHealth；K8s workload cost → Kubecost / OpenCost（不在本表、後續候選）。共同議題：tag governance、cost center mapping、cadence。

下一步路由

• 上游：9.3 壓測工具選型
• 上游：9.10 Production-Side 驗證
• 服務路徑：Checkout 服務演進
• 平行：06 Reliability vendors — 06 從驗證流程看工具，09 從容量量化與效能工程看工具