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

本文承接 終端機圖形化工具總覽 的檔案瀏覽分類。

兩種介面範式：樹狀與 Miller 欄狀

檔案管理器的版面分兩種範式，直接決定操作手感，也是「我記得的是哪一個」最快的辨認點。

樹狀（tree）範式像 IDE 的左側邊欄：一棵可展開、收合的目錄樹，深層結構的層級關係一眼看到。broot 是代表，它的官方定位就是「tree-like view」，配上模糊輸入過濾能直接跳到深層目錄，--max-depth 還能控制樹要展開幾層。

Miller 欄狀（Miller columns）範式像 macOS Finder 的欄狀檢視：並列數欄（父目錄、當前目錄、預覽），游標右移進入子目錄、左移回上層，最右欄即時預覽當前檔案內容。yazi 與 ranger 走這條，預覽窗大、適合邊瀏覽邊讀內容。

辨認方式很單純：記得的是「可展開／收合的樹」就是 broot 這類；記得的是「左邊瀏覽、右邊一大塊預覽」就是 yazi／ranger 這類。

工具對照

broot 把目錄做成可展開的樹，輸入幾個字就模糊過濾並跳轉到符合的路徑，是深層 monorepo 裡找檔最快的範式。它的 br shell function 讓退出時把工作目錄切到所在位置，等於用它當互動式 cd — 純 broot 指令做不到這件事，因為子行程改不了父 shell 的目錄。br 不會自動就位：首次執行 broot 會跳出提示問是否安裝（答 Y，或手動跑 broot --install），它把函式寫進 shell rc，重新載入 rc 後改用 br 啟動。如果還沒安裝 br，在 broot 裡按 Alt + Enter（:cd）跳轉會看到 This verb needs broot to be launched as br 的提示 — 這就是還沒透過 br 啟動的訊號，裝好 br 並改用 br 啟動就能跳轉。

操作上記幾個鍵就夠：直接打字會即時模糊過濾目錄樹，方向鍵移動游標；目錄上 Enter 進入該層、Alt + Enter（verb :cd）離開 broot 並把 shell 切到該目錄、檔案上 Enter 用預設程式開啟；Ctrl + q 離開，Esc 退回上一層狀態。完整快捷鍵與 verb 清單按 ? 叫出。深層結構需要綜觀層級時，樹狀比欄狀直觀。要注意 broot 是導覽與啟動器、不內建文字編輯：改檔得在檔案上開外部編輯器（叫出 $EDITOR），它的強項在樹狀導覽與跳轉，不在看內容或改內容。

yazi 是 Miller 欄狀的現代實作，Rust 寫、預覽走非同步，大目錄或檔案很多時捲動不卡。它的程式碼預覽內建語法高亮（用內建 highlighter、開箱就有彩色，不必另裝相依，實測程式碼確實彩色渲染）；圖片預覽則看終端機支援度（見最後一節）。要的是「邊瀏覽邊看大塊內容」且在意速度時，yazi 最順。

ranger 是 Miller 欄狀的老牌，外掛、設定檔分享與教學資源最多。它的取捨在依賴：ranger 是 Python，遠端機器要有 Python runtime，而且較新的 Python 版本會在啟動時印 deprecation 警告（實測 ranger 1.9.4 配 Python 3.14 會噴 SyntaxWarning: 'return' in a 'finally' block，功能不受影響但訊息惱人）。預覽渲染同樣靠外部相依：ranger 預設的程式碼預覽是純文字、無語法高亮，要彩色得另裝 highlight、bat 或 pygments 並啟用 previewer（實測沒裝這些時就只有純文字，與 yazi 開箱即有高亮形成對比）。生態與依賴是它的一體兩面。

nnn（C）與 lf（Go）走輕量路線，啟動極快、資源佔用低，適合老舊或資源吃緊的機器；lf 是單一 binary，搬檔即用。

遠端情境的選型

選型回到「要哪種瀏覽範式」加上「目標機器能裝什麼」兩條軸：

• 想要 IDE 式可展開樹、常跳深層目錄：選 broot，樹狀加模糊跳轉在深層結構找檔最快。
• 想要欄狀導覽加強預覽（看圖、讀程式碼）、在意速度：選 yazi。
• 已有 ranger 習慣或需要特定外掛：選 ranger，但先確認遠端有 Python、並接受啟動時的警告訊息。
• 受限或老舊機器、要單一 binary 搬過去就用：lf（Go）或 nnn（C）。

安裝依賴是遠端的隱性分界。編譯型工具（broot、yazi、lf、nnn）搬一個 binary 就近可用；ranger 的 Python 依賴在不給裝套件或 Python 版本尷尬的機器上較麻煩。編譯型的單一 binary 仍要留意 glibc／musl 對得上目標系統，這點與 git 工具相同，見 git 線圖工具選型 的單一 binary 注意事項。

預覽能力有一條邊界要先知道：程式碼與純文字檔的預覽在任何終端機都穩定，但圖片預覽需要終端機支援影像協定（sixel／kitty）。純文字遠端通道下，沒有影像協定時圖片會退回檔名與中繼資訊，這與 總覽 對影像協定的取捨一致。

下一步路由

• 把檔案管理器擺進可持久化的多工器 pane：tmux 基礎。
• 編譯型工具搬到遠端的單一 binary 注意事項：git 線圖工具選型。
• 檔案管理在遠端工具分類中的定位：終端機圖形化工具總覽。