這篇按「你原本用什麼」對照現代替代品，講清楚每個替代品解掉原工具的什麼痛點、什麼情境值得換、以及換了要注意的地方。核心的搜尋三件套（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 與套件清單。

本文承接 終端機圖形化工具總覽 的訊息佇列客戶端分類。broker 端的純指令操作與 vendor 選型見 Kafka、Redis Streams、RabbitMQ 服務頁。

跟 SQL 客戶端最大的不同：多半綁單一 broker 協議

訊息佇列 TUI 幾乎都綁定單一 broker 協議，這是選型要先認清的一點，也跟 SQL 客戶端剛好相反。SQL 客戶端 一個工具靠 adapter 連 Postgres、MySQL、SQLite 多種資料庫；訊息佇列這邊，Kafka 的 TUI 說的是 Kafka protocol、不認 AMQP，RabbitMQ 的 TUI 走 management API、也不讀 Kafka topic。能同時連多種 broker 的工具是少數例外（見後文 queuepeek）。

所以選型順序是先定 broker、再挑該 broker 生態的工具。實機盤點下來，Kafka 的 TUI 生態最成熟（多個活躍專案、安裝管道齊全），Redis 有強的增強型 REPL，RabbitMQ 與跨 broker 工具仍在早期。

兩種範式：全螢幕 TUI 與增強型 REPL

訊息佇列客戶端沿用跟 SQL 客戶端同一組範式區分。全螢幕 TUI（kaskade / yozefu / ktea）把 topic 清單、訊息內容、consumer 狀態排進多個面板，鍵盤導航瀏覽；增強型 REPL（iredis）仍是一行行打指令，但加上補全、語法高亮與型別感知輸出，是原生 client 的升級版。

選哪種看工作型態：要在多個 topic 間翻訊息、看 partition 與 consumer group 全貌，用全螢幕 TUI；要快速接上跑幾條指令、或塞進腳本，用增強型 REPL。

Kafka 全螢幕 TUI：kaskade、yozefu、ktea

Kafka 有三個定位不同的全螢幕 TUI，互動模型與連線設定各異。

kaskade（Python、Textual 寫，實測 4.0.7）分 admin 與 consumer 兩個子命令，連線參數走 -b。kaskade admin -b localhost:9092 進管理模式，實測連上 broker 後渲染出 topics 面板，欄位是 name、partitions、replicas、in sync、groups、members、records，一頁看完叢集的 topic 全貌。kaskade consumer -b localhost:9092 -t orders --from-beginning 進消費模式翻單一 topic 的訊息，-v json 與 -v registry 切 payload 解碼方式，後者配 --registry url=http://localhost:8081 接 Schema Registry。SSL / SASL 不走 -b，要用 --config security.protocol=SSL 逐項帶或 --config-file kafka.properties 餵設定檔。

yozefu（Rust 寫、binary 名是 yozf，MAIF 維護）主打跨 topic 的搜尋查詢，把找特定 record 當成核心場景。它的查詢語言是 SQL 風的，預設 initial_query 是 from end - 10（從尾端往回取 10 筆），search filter 還能用 WebAssembly 自訂（create-filter / import-filter 子命令）。連線走 config 模型而非純 flag：yozf config 會印出設定（檔案在 ~/Library/Application Support/io.maif.yozefu/config.json），每個 cluster 在裡面定義 bootstrap.servers、security.protocol 與 schema registry，再用 yozf -c <cluster> -t <topics> 指定要連哪個。

ktea（Go 寫，Homebrew 0.8.0）同樣是 config-based，cluster 連線設定走首次啟動的互動流程而非命令列旗標。啟動旗標有 -debug 與 -plain-fonts，後者在終端機沒裝 NerdFonts、圖示顯示成亂碼時關掉圖示。本機裝起來、啟動旗標確認過，cluster 連線與深層瀏覽走互動設定流程、未逐步驗證。

判讀：要一頁看完 topic / consumer group 狀態、或邊看邊消費，選 kaskade；要在大量 topic 裡用查詢撈特定 record，選 yozefu 的搜尋模型；ktea 是另一個 Go 單 binary 選擇、偏好互動式設定 cluster 的可評估。

增強型 REPL：iredis（Redis 與 Redis Streams）

iredis（Python 寫，實測 1.16.1）是 redis-cli 的增強版，補上指令補全、語法高亮與型別感知輸出，手感仍是 REPL。它跟 dbcli 家族的 pgcli / litecli 同一類定位。實測非互動可跑，把指令用管線餵進去就回結果：echo "DBSIZE" | iredis -h localhost -p 6390，適合塞腳本。

它對 Redis Streams（03 的 vendor 之一）的檢視特別省事。peek <key> 會先看型別再自動取值，string 顯示 strlen 與內容、stream 走 XINFO；實測對一個 stream 跑 XINFO STREAM 直接回 length、last-generated-id 等欄位，不必先 TYPE 再決定下哪個讀取指令。它是通用 Redis client、不是 stream 專用工具，但 Redis Streams 的 consumer group 操作（XPENDING、XCLAIM、XINFO GROUPS）都在這套指令補全範圍內。

RabbitMQ 與跨 broker：生態仍在早期

RabbitMQ 與「一個工具連多種 broker」這兩塊目前缺乏可直接安裝驗證的成熟工具，列出供參考、本機未實機驗證。

RabbitMQ 的 TUI 候選有 rabbitui（走 RabbitMQ management API）與 rabbithole（帶 exchange / binding 的 topology browser、支援 Protobuf 解碼）。兩者都不在 Homebrew 與 crates.io 的發佈管道，本機未安裝驗證。在缺 TUI 的情況下，RabbitMQ 的互動瀏覽仍以內建的 Management UI（web，預設 15672 埠）為主，純終端機則回到 rabbitmqctl 與 rabbitmqadmin。

跨 broker 的 queuepeek（Rust 寫，宣稱同時連 RabbitMQ、Kafka、MQTT）對應 SQL 類裡 usql 的「一個工具連多種後端」定位。本機 cargo install queuepeek 在編譯 rdkafka-sys（綁定原生 librdkafka）階段失敗、未能驗證。

gotcha（實測）

• yozefu 預設帶一個名為 localhost 的 cluster、指向 localhost:9092。連非預設 port（例如本機測試的 9093）要先 yozf configure 改掉 bootstrap.servers，直接用 flag 覆寫不會生效。
• kaskade 的 -b 只接 bootstrap server；SSL / SASL 等安全設定一律走 --config key=value 或 --config-file，混在 -b 裡會被當成 broker 位址。
• ktea 的 -plain-fonts：終端機沒裝 NerdFonts 時圖示會顯示成亂碼方塊，加這個旗標關掉圖示就恢復可讀。

同類其他選擇

Redis 的全螢幕 TUI（如 redis-tui）與其他 Kafka TUI（如 kafka-tui）未在本輪實機驗證、列出供參考。Kafka TUI 這塊專案數量較多，挑選時以發佈管道（Homebrew / pip / crates.io 直接可裝）與維護活躍度篩選，不追求窮舉。

下一步路由

• broker 端純指令工具與 vendor 選型：Kafka、Redis Streams、RabbitMQ 服務頁。
• 同範式的資料庫客戶端對照：終端機 SQL 客戶端。
• 把客戶端擺進可持久化的多工器 pane：tmux 基礎。
• 訊息佇列客戶端在遠端工具分類中的定位：終端機圖形化工具總覽。

遠端伺服器優先選 tmux 的理由是可用性。它幾乎是事實標準，多數 Linux 發行版的套件庫都有、很多伺服器甚至預裝。zellij 功能新、畫面提示友善，但通常要自行安裝；在不能隨意裝套件的機器上，tmux 處處可用就是決定性優勢。兩者的取捨在最後一節展開。

本文承接 終端機圖形化工具總覽 的多工器分類，聚焦 tmux 在遠端情境的實際操作。

持久化工作流：detach 與 reattach

tmux 對遠端最重要的能力是 session 持久化：session 跑在伺服器上，跟當前這條 SSH 連線無關，所以主動離開或被動斷線後它都還在。這條工作流由四個指令構成。

關鍵在於被動斷線與主動 detach 的結果相同：手機從 Wi-Fi 切到行動網路、SSH 連線逾時、筆電闔上，這些情況下 tmux session 都留在伺服器上，重連後 tmux a 就接回去。判讀訊號很單純：任何超過幾秒、不想因斷線重來的工作（build、資料遷移、tail -f 追 log、跑測試），開始前先進 tmux。

prefix key：tmux 操作的入口

tmux 的所有指令都以 prefix key 起手，預設是 Ctrl-b。操作方式是按下 Ctrl-b 放開、再按功能鍵，而不是同時按住。理解這個「兩段式」是上手 tmux 的第一道門檻；若按住不放或間隔太久而沒反應，多半是兩段式沒按對，重來一次即可。

window 與 pane 是兩個層級：window 是整頁工作區（類似分頁），pane 是一個 window 內切出的子區塊。遠端開發常見的佈局是一個 window 切成數個 pane，一個跑編輯器、一個跑 tail -f、一個留著敲指令。捲動歷史要先進 copy mode（prefix 後按 [），用方向鍵或 PageUp 往回看，按 q 離開 — 這是初學最容易卡住的點，因為進了 tmux 後終端機原本的捲動行為改由 tmux 接管。

遠端與手機的調校

tmux 預設設定對手機與慢速連線不夠順，幾項調整能明顯改善體感，全部寫在 ~/.tmux.conf。

prefix key Ctrl-b 在手機虛擬鍵盤上難按，常見的調整是改綁成 Ctrl-a（更靠近鍵盤左側）：

1# ~/.tmux.conf
2unbind C-b
3set -g prefix C-a
4bind C-a send-prefix

滑鼠支援讓觸控裝置能直接點選 pane 與捲動，在手機與平板特別有用：

1# ~/.tmux.conf
2set -g mouse on

頻寬層面，tmux 本身傳輸的是純文字、量很低，斷線重連的成本也小。真正吃頻寬的是跑在 tmux 裡的全螢幕 TUI（例如 btop）的高頻重畫 — 這要調的是那個工具自己的刷新率，而非 tmux。改完設定檔後，在既有 session 內用 prefix 後按 : 輸入 source-file ~/.tmux.conf 重新載入。

tmux 與 zellij 的選型對照

tmux 與 zellij 解決同一類問題，session 持久化是兩者共有的基本能力（zellij 甚至內建 resurrection），真正的選擇依據是可用性與上手成本。

選型分界很清楚：受限或陌生的伺服器、要求處處可用，選 tmux；自己掌控的機器、想要友善的上手體驗與內建 layout，選 zellij。對 prefix 快捷鍵還不熟的人，這條分界仍成立：在別人的伺服器上工作優先學 tmux，因為無法保證對方裝了 zellij，可用性約束高於上手體驗；zellij 的友善體驗留給自己能掌控安裝的機器。兩者的指令心智模型相近（都靠一個 prefix/modifier 起手），學會一個再換另一個成本不高。zellij 路線的實際操作在本資料夾另有兩篇：pane 的 CLI 操作見 Zellij 多終端機操作指南、瀏覽器遠端連線見 Zellij Web Client 外網連線教學。

下一步路由

• 在多工器的 pane 裡擺即時監控：見 TUI 監控工具。
• zellij 的進階用法：Zellij 多終端機操作指南 與 Zellij Web Client 外網連線教學。
• 多工器在三類遠端工具中的定位：終端機圖形化工具總覽。

本文承接 終端機圖形化工具總覽 的 TUI 工具脈絡，聚焦系統監控這一支在遠端的實際使用與調校。git 線圖工具（tig / lazygit / gitui）雖然也是 TUI，但屬版控子題，獨立成 遠端 CLI 開發的 git 線圖工具選型。

htop：進程層的標準

htop 把進程清單畫成帶 CPU 與記憶體長條的全螢幕視圖，責任是即時看進程並直接操作。它用底部的功能鍵列引導操作，不必背指令。

遠端使用的關鍵是刷新延遲。htop 用 -d 設定刷新間隔，單位是十分之一秒，所以 htop -d 30 是每 3 秒刷新一次。慢速連線下把延遲調大換取畫面不卡、按鍵不延遲，可從 5 秒（htop -d 50）起步，順了再往下調。這個 5 秒是經驗起點、不是測得的閾值，實際依連線 RTT 與終端尺寸調整（後面 btop 與判讀段沿用此基準）。

btop：多資源儀表板

btop 把 CPU、記憶體、網路、磁碟畫在同一畫面，並帶歷史曲線與滑鼠操作，責任是一眼總覽多個資源維度的趨勢。相較 htop 偏進程清單，btop 偏向整機儀表板。

刷新率是 btop 在遠端最該調的設定。它的刷新間隔由 update_ms 控制（預設 2000 毫秒），把間隔調短會讓全螢幕重畫更頻繁、在慢速連線吃掉頻寬。調整方式是按 Esc 開 Options 選單改 update_ms，或直接編輯設定檔 ~/.config/btop/btop.conf 的 update_ms 值。判讀分界與 htop 相同：連線品質好可用較密的刷新換即時性，品質差就把間隔拉長，慢速連線可從 update_ms 5000（5 秒）起步。

k9s：Kubernetes 叢集導航

k9s 把 kubectl 的查詢與操作做成全螢幕導航介面，責任是讓叢集管理不必逐條敲 kubectl 指令。它用冒號指令切換資源視圖，游標選中資源後用快捷鍵操作。

安裝與 --refresh 旗標已實機驗證；以下 :pods 等叢集操作需連到 k8s cluster，依官方用法、本機未實機驗證。

常見操作是輸入 :pods 看 pod 清單、:svc 看 service，游標停在某個 pod 上按 l 看 log、d 看 describe、s 進 container shell。對遠端管理叢集的情境，它把「查狀態到進去除錯」的流程收進同一畫面，省去反覆切換指令的負擔。k9s 同樣是全螢幕 TUI、會定期輪詢叢集狀態，慢速連線下導航延遲明顯時，可在啟動時用 --refresh 把輪詢間隔（秒）調長。

其他常用 TUI 監控

不同資源維度有各自的專用 TUI，責任聚焦在單一面向。

這些工具的共同特性是各管一個維度：磁碟爆了用 ncdu 找出是哪一包、容器資源異常用 ctop 定位、要拆解 image 肥在哪用 dive。遠端排查時依問題維度挑對應工具，比開一個大而全的儀表板更直接。

Docker 相關的兩個工具值得多記一筆。dive 除了 TUI，還有非互動的 --ci 模式：dive <image> --ci 會輸出 image 的 efficiency 與 wasted space，並依門檻判定 pass/fail，適合塞進 CI pipeline 擋住臃腫 image。ctop 的單一容器細節視圖（游標選中按 Enter）會把環境變數明文列出，含資料庫密碼這類敏感值，共享畫面或側錄時要留意。

遠端刷新率與頻寬的取捨

全螢幕 TUI 監控的遠端成本核心在於：每次刷新會重送整片字元矩陣，刷新越密、頻寬負擔越重。慢速連線下會看到畫面延遲、按鍵反應慢。對策是把刷新間隔調長（htop -d、btop 的 update_ms），用更新頻率換流暢度。

判讀分界落在刷新率與監控粒度：連線順暢時用 1–2 秒的密集刷新看即時變化；連線吃緊時把間隔拉到 5 秒以上，或當只盯單一指標時改用一次性的文字趨勢（見 終端機文字圖表）而非全螢幕儀表板。

下一步路由

• 把監控擺進可持久化的多工器：tmux 基礎，斷線後 reattach 回去監控還在跑。
• 一次性的文字趨勢圖（省頻寬的替代）：終端機文字圖表。
• 監控的是 web 請求而非系統資源：終端機看 nginx 請求（GoAccess / ngxtop）。
• TUI 監控在遠端工具分類中的定位：終端機圖形化工具總覽。

本文承接 終端機圖形化工具總覽 的資料庫客戶端分類。工具分兩種範式：全螢幕 TUI 客戶端，與增強型 REPL。

兩種範式：全螢幕 TUI 與增強型 REPL

全螢幕 TUI（harlequin / lazysql）把 schema 樹、查詢編輯器、結果表格排進多個面板，像縮小版的 DBeaver。增強型 REPL（pgcli / litecli）仍是一行一行打 SQL，但加上語法高亮、智能補全與表格化輸出，是 psql / mysql 原生 client 的升級版。

選哪種看工作型態：要邊看 schema 邊探索資料，用全螢幕 TUI；要快速接上跑幾條查詢、或塞進腳本，用 REPL。

全螢幕 TUI：IDE 風與瀏覽器風

兩個全螢幕 TUI 的互動模型剛好相反，這是選型最該先分清的一點。

harlequin 是 SQL IDE 風：左側 Data Catalog 樹列出 db → schema → table → 欄位（帶型別標記，整數 #、字串 s、numeric #.#），中間是查詢編輯器，寫好 SQL 按 Ctrl+Enter 執行、結果在下方表格。點表只是把表的限定名稱插進編輯器、輔助組查詢，不會自動顯示資料。它用 Python（Textual）寫，adapter 涵蓋 postgres、mysql、sqlite、duckdb、odbc，預設 adapter 是 duckdb，連別的 DB 用 -a 指定，例如 harlequin -a postgres "<連線字串>" 或 harlequin -a sqlite db.sqlite。

lazysql 是瀏覽器風：左側選一個表，右邊直接顯示該表記錄、不必寫 SELECT。上方分頁切 Records / Columns / Constraints / Foreign Keys / Indexes（[ 與 ] 切換）。篩選按 / 開 WHERE 輸入，帶運算子補全（=、≠、>、between、ilike、in、like、regexp 等），只寫條件、不用整句。要跑自訂 SQL 按 Ctrl+E 開編輯器（vim modal、有 -- INSERT -- 模式）寫完整語句、Ctrl+R 執行。它用 Go 寫、lazygit 風的鍵盤導航。

判讀：習慣先寫 query 再看結果的選 harlequin；習慣點開表瀏覽、偶爾才下複雜 SQL 的選 lazysql。

dblab（Go）與 rainfrog（Rust）是另外兩個實機驗證過的瀏覽風 TUI。dblab 走混合型：左側樹（Ctrl+H 聚焦、j/k 移動、Enter 看表的列）配上方查詢編輯器（Ctrl+E 執行），瀏覽與寫 query 兩條路都有。它有一個實測 gotcha：編輯器的查詢要 schema 限定（SELECT * FROM public.products 才行、裸 products 會報 relation 不存在），因為編輯器連線的 search_path 沒含 public，而樹瀏覽（Enter）不受這點影響。rainfrog 專注 Postgres：側欄選表看 rows / columns / constraints / indexes / rls policies，查詢編輯器是 vim modal（i 進 insert、v 進 visual），另有 history 與 favorites 分頁。實測它不支援滑鼠操作，面板與分頁一律用 Tab 切換、其餘靠鍵盤導航。

增強型 REPL：dbcli 家族

pgcli（Postgres）、mycli（MySQL）、litecli（SQLite）是同一個專案（dbcli）的三個 client，把原生 psql / mysql / sqlite3 補上智能補全（表名、欄位、關鍵字）、語法高亮與對齊的表格化輸出。手感仍是 REPL，但打 SQL 時會即時提示。

它們也能非互動執行、適合腳本：litecli 用 -e（litecli db.sqlite -e "SELECT ..."），pgcli 在 stdin 非 TTY 時讀管線（echo "SELECT ..." | pgcli "<連線字串>"），輸出是對齊的 ASCII 表格。要在腳本裡取一次查詢結果、又想要比 psql -c 更好的排版時，這條路最直接。

usql 走另一條路：universal CLI，一個工具用統一介面連 Postgres、MySQL、SQLite 等各種 DB，連線字串以 scheme 區分（postgres://...、sqlite:...），也支援 -c 非互動執行。它不是 TUI，行為像能連多種 DB 的加強版 psql。一台機器要連好幾種不同 DB 時，一個 usql 比每種 DB 各裝一個 client 省事。

遠端連線的一個 gotcha：SSL 模式因 driver 而異

同一個 Postgres、同一條連線字串，不同 client 的 SSL 預設不一樣。lazysql 走 Go 的 pq driver、預設要求 SSL，連沒開 SSL 的 DB 會報 pq: SSL is not enabled on the server，要在連線字串加 ?sslmode=disable：postgresql://user:pass@host:5432/db?sslmode=disable。pgcli 與 harlequin 走 Python 的 psycopg、預設行為不同，同樣的 DB 不加也能連。遠端連不上、又確定帳密與 port 對的時候，先查的就是 sslmode。

同類其他選擇

同範式還有 gobang（Rust）。它未上 crates.io、Homebrew 也沒有對應 formula，本機未能安裝，列出供參考、未實機驗證。

下一步路由

• 把 DB client 擺進可持久化的多工器 pane：tmux 基礎。
• 編譯型工具（lazysql / dblab / rainfrog）搬到遠端的單一 binary 注意事項：git 線圖工具選型。
• SQL 客戶端在遠端工具分類中的定位：終端機圖形化工具總覽。

這類工具與 TUI 監控的分工很清楚：TUI 監控自己去抓系統即時狀態並持續刷新，文字圖表則是餵什麼畫什麼，適合畫已經到手的數值（log 抽出的延遲、監控匯出的指標、一個查詢的結果）。本文承接 終端機圖形化工具總覽 的文字圖表分類。

gnuplot：通用繪圖的 ASCII 後端

gnuplot 是老牌繪圖工具，設定 set terminal dumb 就改用 ASCII 字元輸出，責任是把函數或時間序列畫成終端機可讀的折線圖。它不需要圖形環境，在純 SSH 下直接可用。

1gnuplot -e "set terminal dumb size 80,25; plot sin(x)"

畫資料檔時把 plot 指向檔案，例如 plot 'data.dat' using 1:2 with lines。gnuplot 的適用情境是需要正式座標軸、多條曲線疊圖、或畫數學函數時 — 它的表達力最完整，代價是設定語法較多。

termgraph：分類長條圖

termgraph 吃一份「標籤加數值」的資料就畫出橫向長條圖，責任是讓各分類的佔比一眼可比。它用 pip install termgraph 安裝，適合看「哪一類佔最多」這種分布問題。

1printf "Mon 120\nTue 250\nWed 90\n" | termgraph

每一行是一個分類與其數值，termgraph 把數值換算成等比例的長條。它的定位是快速看分布，不追求座標軸的精確 — 想看的是相對大小而非絕對讀數時最合適。

plotext：腳本內繪圖

plotext 是 Python 函式庫，讓折線、散點、長條圖直接在腳本裡畫出來，責任是把繪圖接在資料處理流程後面。它用 pip install plotext 安裝，適合在既有的 Python 資料處理腳本末端加一段視覺化。

1import plotext as plt
2
3plt.plot([3, 1, 4, 1, 5, 9, 2, 6])
4plt.title("延遲趨勢")
5plt.show()

plotext 的優勢是與資料處理同在一個腳本、不必把資料另存再餵給外部工具。處理完數據順手畫一張圖確認形狀，是它最自然的用法。

sparkline 與 pipeline 即時更新

sparkline 工具把一串數字壓成一行高低起伏的點陣，責任是用最小的版面塞進一條趨勢。它不畫座標軸，只呈現形狀，適合放進狀態列、log 或窄螢幕。

1spark 1 5 3 8 2 9 4

需要從 pipeline 即時吃資料時，youplot（指令名 uplot）能接管線畫圖，配合 tail -f 做出滾動更新的監控線：

1tail -f metrics.log | uplot line

sparkline 在窄螢幕（手機、平板遠端）特別有優勢，因為一行不管螢幕多窄都塞得下。低頻率印一條 sparkline 來持續觀察某個指標，比開全螢幕儀表板省頻寬得多。

遠端使用判讀

文字圖表在遠端的核心優勢是輸出模式：一次性印出、不持續重畫，所以不像全螢幕 TUI 那樣持續佔用頻寬。判讀分界落在資料來源與互動需求 — 手上已有數值、只想看形狀，用文字圖表；需要系統即時狀態並隨時操作，用 TUI 監控（見 TUI 監控工具）。

慢速連線下做持續監控時，「每隔較長間隔印一次 sparkline 或長條圖」比全螢幕儀表板省頻寬：一行 sparkline 的傳輸量是固定的幾十個位元組，全螢幕儀表板則每次重送整片畫面（含 ANSI 色碼常達數 KB），兩者差一到兩個量級。

下一步路由

• 需要即時系統狀態而非一次性圖表：TUI 監控工具。
• 把監控與繪圖擺進可持久化的多工器：tmux 基礎。
• 文字圖表在整個遠端工具選型中的位置：終端機圖形化工具總覽。

本文承接 終端機圖形化工具總覽 的 TUI 工具脈絡，屬監控的 web 請求子題。但比起工具本身，更該先分清的是「什麼時候用終端機看請求、什麼時候不該」，這放在最後一節。

GoAccess：即時請求儀表板

GoAccess 把 access log 解析成全螢幕的即時儀表板，責任是把一份 log 變成可讀的請求分析：狀態碼分布、top 請求路徑、不重複訪客、頻寬、回應時間、訪客的 OS 與瀏覽器。它既能開互動 TUI，也能輸出 HTML／CSV／JSON 報表。

驗證它解析的正確性可以走非互動模式 — 餵一份 nginx access log、指定格式、輸出報表：

1goaccess access.log --log-format=COMBINED -o report.html

--log-format=COMBINED 是對應 nginx 標準 combined 格式的預設。實測對一份 13 筆請求的 log，GoAccess 正確分出 9 筆 2xx、4 筆 4xx，並列出 top 路徑（/ 佔多數、/missing 等 404）、訪客 host、user-agent 與頻寬。互動模式（不加 -o）則是同一份資料的全螢幕即時版，連線中持續更新。

ngxtop：top 風格的請求即時表

ngxtop 把 access log 做成 top 風格的即時表，責任是用最精簡的版面看「現在最熱的請求路徑與其狀態碼分布」。它比 GoAccess 輕、聚焦在請求路徑與狀態碼，適合快速掃一眼。

1ngxtop -l access.log --no-follow

--no-follow 處理現有 log 後就退出（預設會持續跟隨新進的 log）。

這裡有一個實測會撞到的 gotcha：ngxtop 的 log 格式要跟實際的 nginx log_format 完全對上，否則它靜默回 0 records。nginx 官方 image 的預設 log_format 在標準 combined 之後多了一個 "$http_x_forwarded_for" 欄位，ngxtop 的預設格式不含它，結果就是「跑得起來、但一筆都沒解析到」。對策是用 -f 餵實際的格式：

1ngxtop -l access.log --no-follow \
2  -f '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for"'

格式對上後，ngxtop 正確處理 13 筆、分出 9 筆 2xx 與 4 筆 4xx，跟 GoAccess 的結果一致。相較之下 GoAccess 的 --log-format=COMBINED 對尾端多出的欄位較寬容。判讀訊號很明確：ngxtop 顯示 0 records 時，先懷疑的是格式沒對上，而非沒有流量。

何時用終端機看請求、何時不該

工具會用之後，真正該分清的是使用時機。監控 nginx 請求依目的走兩條完全不同的路。

當下排查與 ad-hoc 觀測，用終端機。情境是「伺服器現在很忙，進去看誰在打」「某個 endpoint 的 5xx 突然變多，即時看是哪一條」。這時 GoAccess／ngxtop／tail -f access.log 直接在那台機器上看當下狀況，是遠端 SSH 除錯的日常，也是這類 TUI 工具的主場。

持續的生產監控，不用終端機。沒有人 24 小時盯著 GoAccess。生產環境的請求監控走 pipeline：指標面用 nginx 的 stub_status（基礎）或 VTS 模組／nginx-prometheus-exporter（細到 per-status、per-upstream 的請求率），由 Prometheus 抓、Grafana 畫儀表板並設告警；日誌面把 access log 送到 Loki／ELK／Datadog 之類做查詢與長期保存。

分界濃縮成一句：終端機 TUI 答「這台機器現在怎樣」，pipeline 答「趨勢如何、超標叫我」。所以請求一直都有被監控，只是持續監控的那份在 Prometheus 與日誌平台、不在終端機。生產 pipeline 的設計（metrics、dashboard、SLO、告警與 vendor 選型）屬後端觀測性的範圍，見 可觀測性平台；當排查升級成事故、需要止血與復盤的協作流程時，見 事故處理與復盤。

下一步路由

• 系統資源（CPU／記憶體／磁碟）的即時監控：TUI 監控工具。
• 把即時觀測擺進可持久化的多工器 pane：tmux 基礎。
• 這類工具在遠端工具分類中的定位：終端機圖形化工具總覽。

這類工具常被誤解成「把圖片塞進終端機」。那是另一條技術路線（sixel、kitty 影像協定、chafa 把 PNG 轉成色塊），依賴特定終端機支援、傳輸量大，在低頻寬遠端會卡。本篇談的是另一條路線：用 ─│┌┐└┘ 這類製圖字元、用半形與全形方塊堆出長條圖、用 sparkline 點陣畫趨勢線。畫面本質仍是一段文字，任何能顯示文字的終端機都能呈現。

為什麼遠端操作特別需要這條路線

遠端操作的核心限制是頻寬與連線穩定度，而純文字介面正好把這兩個成本壓到最低。一個全螢幕的監控介面，每次刷新送出的是一整片字元矩陣；若改用影像協定，送出的是一張壓縮點陣圖，資料量通常相差一個量級以上（實際視壓縮率而定）。連線中斷時，文字介面只要重連就能重畫，影像協定則可能因終端機狀態錯亂而花屏。

這條路線也避開了環境依賴。遠端伺服器通常沒有桌面環境，X11 forwarding 設定繁瑣又吃頻寬；手機上的 SSH app（Termius、Blink、JuiceSSH）能穩定顯示的就是文字。把操作介面建立在文字之上，等於把「能不能用」的前提降到「終端機能顯示字」，這是所有遠端通道都滿足的最低標準。

六類工具的定位

終端機圖形化工具依本篇關注的責任分六類，各自解決遠端操作的不同問題。這裡聚焦「監控判讀、資料可視化、多工承載、檔案瀏覽、資料庫存取、訊息佇列存取」六種責任；fuzzy finder（fzf）等其他互動式 TUI 同屬純文字遠端路線、但責任不同，不在本篇的選型框架內。

TUI 監控與儀表板

TUI（Text User Interface）監控工具負責把系統即時狀態畫成全螢幕的互動介面，省去反覆敲 ps、df、free 再自行拼湊的步驟，一眼呈現 CPU、記憶體、磁碟、網路的即時變化。它用製圖字元畫出框線與長條，用顏色標出負載高低，並接受鍵盤操作來排序、過濾、殺進程。

btop 與 htop 是系統層的代表：開起來就是一片帶長條圖的進程清單，可以直接選中進程送訊號。k9s 把這套搬到 Kubernetes，用同樣的全螢幕互動瀏覽 pod、查 log、進 container。lazygit 把 git 的暫存、commit、分支操作變成可點選的面板。ncdu 與 gdu 掃描磁碟並用長條畫出每個目錄佔多少空間，找出爆掉的是哪一包。

這類工具的共同判讀訊號是：需求落在「即時狀態 + 立刻操作」、而非「事後分析一段歷史資料」時，TUI 監控是對的選擇。它的邊界在於刷新成本 — 全螢幕重畫在慢速連線上會明顯延遲，這點在後面遠端情境會展開。

ASCII 與文字圖表

文字圖表工具負責把一串數值畫成終端機裡的圖，讓趨勢與分布可視化，而不必把資料下載回本機開試算表。它接受標準輸入或檔案的數字，輸出長條圖、折線圖或 sparkline，全部由字元構成。

gnuplot 是老牌繪圖工具，設定 set terminal dumb 就會用 ASCII 畫折線圖，適合畫函數或一段時間序列。termgraph 吃一份「標籤 + 數值」就畫出橫向長條圖，看各分類佔比很直接。plotext 是 Python 函式庫，在腳本裡直接畫折線與散點，適合接在資料處理流程後面。youplot（uplot）能從 pipeline 即時吃資料畫圖，配合 tail -f 可以做出滾動更新的監控線。sparkline 類工具（如 spark）把一串數字壓成一行高低起伏的點陣，塞進狀態列或 log 裡都行。

這類工具的判讀訊號是：手上已經有一串數值（log 抽出來的延遲、監控匯出的指標、一個查詢的結果），想看形狀而非逐筆讀數字。它跟 TUI 監控的差別在於資料來源 — TUI 監控自己去抓系統即時狀態，文字圖表則是餵什麼畫什麼，適合畫自訂指標與歷史資料。

終端機多工器

終端機多工器負責在單一連線裡管理多個終端機 session，並讓 session 的生命週期脫離連線本身。它把畫面切成多個 pane、用分頁組織工作流，而最關鍵的是：連線斷了，伺服器上的 session 仍在跑，重連後 attach 回去就接續原狀。

tmux 是事實標準，幾乎每台伺服器都裝得到，設定檔成熟、資源佔用低。zellij 是較新的選擇，預設就有畫面提示（floating pane、操作提示列），對不熟快捷鍵的人上手較快，並內建 layout 設定能一鍵開出固定的多 pane 佈局。

多工器跟前兩類不同，它本身不畫資料圖，而是承載其他工具的容器：在一個 pane 跑 btop、另一個 pane 跑 tail -f 接 sparkline、第三個 pane 留著敲指令。對遠端操作來說，它解決的是連線穩定度問題 — 這是手機與低頻寬情境的核心痛點，下一節展開。

檔案瀏覽與操作

檔案管理器負責把目錄結構與檔案內容做成可導航的互動介面，讓遠端只有終端機時也能像 IDE 側邊欄那樣瀏覽、預覽、搬移檔案，取代反覆 ls、cd、cat。

broot 用可展開的樹狀檢視呈現目錄層級，配模糊跳轉適合深層結構；yazi 與 ranger 走 Miller 欄狀（並列父目錄、當前目錄、預覽窗），邊瀏覽邊看內容。

這類工具的判讀訊號是：需求落在檔案層級的導覽與操作，而非系統監控或畫圖。選型與依賴注意事項見 終端機檔案管理器。

資料庫存取

資料庫客戶端負責把 DB 的 schema、表格與查詢結果做成文字介面，讓遠端只有終端機時也能連到資料庫瀏覽資料、跑查詢，取代把連線資訊餵給桌面 GUI（DBeaver、TablePlus）。

它分兩種範式：全螢幕 TUI（harlequin 的 SQL IDE 風、lazysql 的瀏覽器風）把 schema 樹、編輯器、結果表排進面板；增強型 REPL（pgcli / litecli）仍是行式打 SQL、但補上語法高亮與智能補全。

這類工具的判讀訊號是：需求落在連資料庫做事，而非看系統或檔案。選型與連線注意事項見 終端機 SQL 客戶端。

訊息佇列存取

訊息佇列客戶端負責把 broker 的 topic、partition、consumer group 與訊息內容做成文字介面，讓遠端只有終端機時也能瀏覽訊息流、消費單一 topic、看消費進度，取代把連線資訊餵給桌面工具（Conduktor、RedisInsight）。它跟資料庫客戶端的關鍵差異是多半綁單一 broker 協議：Kafka 的 TUI 不認 AMQP、一個工具連多種 broker 是少數例外。

它同樣分兩種範式：全螢幕 TUI（Kafka 的 kaskade 看叢集與消費、yozefu 用查詢撈 record）把 topic 清單與訊息排進面板；增強型 REPL（Redis 的 iredis）行式打指令、補上補全與型別感知。

這類工具的判讀訊號是：需求落在連 broker 看訊息與消費狀態，而非連資料庫。選型與實機驗證注意事項見 終端機訊息佇列客戶端。

三種遠端情境的選型判讀

工具選型要回到實際的連線條件，而不只是比對功能清單。以下對應三種常見的遠端情境，各自的判讀重點與陷阱不同。

SSH 連到 Linux 伺服器

從本機 SSH 進伺服器，連線通常穩定、頻寬足，瓶頸在於操作要連續、不想每次重連都從頭開始。這個情境的核心配置是「多工器打底 + TUI 監控擺上去」：登入後先 tmux attach（沒有就 tmux new），在固定的 pane 佈局裡跑監控與操作。

這裡的判讀重點是把 session 持久化當成預設習慣，而不是等斷線才後悔。即使連線穩定，把長時間任務（build、資料遷移、tail -f 追 log）放進多工器，就能隨時離開再回來。TUI 監控在這個情境幾乎沒有刷新成本顧慮，btop 開最高刷新率也順，互動功能的排序與殺進程都能放手用。

常見陷阱是把多工器與終端機本身的捲動搞混 — 進了 tmux 後，滑鼠捲動預設是 tmux 在管，要進 copy mode 才能往回看歷史。這是上手期最容易卡住的點，值得一開始就把捲動與複製的快捷鍵設順。

手機或平板遠端

用手機或平板的 SSH app 連線，限制是螢幕小、虛擬鍵盤難敲組合鍵、連線會隨網路切換而中斷。這個情境最該優先的是多工器的持久化能力：手機從 Wi-Fi 切到行動網路、app 切到背景再回來，連線往往已經斷過一次，沒有多工器就等於每次都重來。

工具選型要往「省版面、少快捷鍵」傾斜。zellij 在這裡比 tmux 友善，因為它把操作提示畫在畫面上，不必硬記組合鍵；但 tmux 若已配好觸控友善的快捷鍵也能勝任。TUI 監控要挑版面能縮的 — htop 在窄螢幕下仍可讀，複雜的多欄儀表板則會被擠到看不清。文字圖表在小螢幕反而有優勢，一行 sparkline 不管螢幕多窄都塞得下。

常見陷阱是組合鍵在虛擬鍵盤上難以輸入。多工器的 prefix key（tmux 預設 Ctrl-b）在手機上很難按，值得改綁成單鍵或螢幕上的快捷按鈕；好的 SSH app 通常提供自訂工具列來補這個缺口。

低頻寬或不穩定連線

連線慢或會斷時，限制同時來自頻寬與穩定度，兩者要分開處理。穩定度由多工器解決 — 斷線後 session 還在，這點與情境無關地成立。頻寬則直接決定 TUI 監控能不能用得舒服。

這裡最關鍵的判讀是刷新率與重畫成本的取捨。全螢幕 TUI 每次刷新會重送整片畫面，刷新間隔越短、頻寬負擔越重；把刷新率調快、或工具本身刷新較密時，慢速連線上會看到畫面追不上、按鍵延遲。對策是把刷新間隔調長（多數工具支援，例如 btop 在介面裡可調 update_ms、htop 用 -d 設延遲），用較低的更新頻率換流暢的操作。

判讀的分界是即時性與頻寬的取捨：連線品質好就用全螢幕 TUI 的即時性，品質差就退回低頻率的文字輸出。文字圖表在後者特別划算，因為它是一次性輸出而非持續重畫 — 跑一次 termgraph 印出結果就結束，不佔用持續頻寬；需要持續監控時，「低刷新率的單一數值 + 偶爾印一次 sparkline」往往比全螢幕儀表板更實用。

選型判準與下一步

把這些工具與三種情境收斂成一條判準鏈：先用多工器解決連線斷續（任何遠端情境都先做這步），再依任務選對應工具 — 即時狀態用 TUI 監控、看歷史數值用文字圖表、找檔案用檔案管理器、連資料庫用 SQL 客戶端、連 broker 看訊息用訊息佇列客戶端，最後依連線品質調整刷新率與版面密度。

這條判準對應的具體工具，在本資料夾逐篇展開安裝、設定與遠端調校的細節：

• TUI 工具：系統監控（btop / htop / k9s）見 TUI 監控工具；web 請求日誌（GoAccess / ngxtop）見 終端機看 nginx 請求；git 線圖（tig / lazygit / gitui）屬版控子題、見 遠端 CLI 開發的 git 線圖工具選型
• 文字圖表：終端機文字圖表（gnuplot dumb terminal、termgraph 與 plotext 的資料接法、sparkline 接 pipeline）
• 多工器：tmux 基礎（持久化與基本操作）；zellij 的 pane 操作見 Zellij 多終端機操作指南、瀏覽器遠端連線見 Zellij Web Client 外網連線教學
• 檔案管理：終端機檔案管理器（broot 樹狀、yazi / ranger Miller 欄狀的選型與依賴）
• 資料庫客戶端：終端機 SQL 客戶端（harlequin IDE 風、lazysql 瀏覽器風、pgcli / litecli 增強 REPL）
• 訊息佇列客戶端：終端機訊息佇列客戶端（Kafka 的 kaskade / yozefu / ktea、Redis 的 iredis、與綁單一 broker 協議的選型差異）

每篇單工具文章會聚焦一個工具在遠端情境下的實際配置，而不是重述官方手冊。先有這份總覽建立選型框架，再依當下的連線條件挑對應的工具深入。

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

兩種介面範式：樹狀與 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 線圖工具選型。
• 檔案管理在遠端工具分類中的定位：終端機圖形化工具總覽。

最基本的線圖能力內建在 git 本身：git log --oneline --decorate --graph 就會用 ASCII 畫出分支線。Oh My Zsh 的 git plugin 把它包成 glog（當前分支）與 gloga（加 --all 看全分支）兩個 alias。這條 alias 是任何環境都成立的底線 — 即使在一台陌生、不能安裝任何東西的機器上，git log --graph 永遠都在。專用工具要解決的，是這條底線之上的兩個缺口：互動瀏覽的流暢度，以及把「看」與「改」整合在同一畫面。

本文承接 終端機圖形化工具總覽 的 TUI 工具脈絡，聚焦 git 線圖這個版控子題（最常被遠端開發者問到）。

三類工具的職責分工

git 線圖工具依承擔的責任分三類，遠端 CLI 情境下各自適用的條件不同。

TUI 互動式瀏覽與操作

TUI 工具負責把 git 歷史開成全螢幕的互動介面，讓游標在 commit、檔案、分支之間移動，並即時在側欄顯示對應的 diff。它跟單純印一次 log 的差別在於「可導航」— 線圖、diff、blame 在同一個畫面裡用鍵盤切換，不必反覆重打指令。

已經在用 tig 的人，可以把後兩者當成「補上操作能力」而非替換：只想瀏覽就停在 tig，要用鍵盤完成 stage/commit/rebase 再加 lazygit，兩者互補。各工具的責任邊界與選型條件在下面逐一展開。

tig 的責任邊界在「看」。它把 git 歷史做成可導航的唯讀視圖，線圖呈現清楚、資源佔用極低，適合只想快速翻歷史與看 diff 的情境。它本身不做版控操作，所以心智負擔小、學習成本低。

lazygit 把責任從「看」擴到「改」。互動式 rebase、cherry-pick、stash 管理、衝突解決、stage 到 commit 的完整流程都能用鍵盤完成，等於把終端機 git 操作整碗端進一個畫面。它的代價是功能多帶來的學習曲線與稍高的資源佔用。

gitui 與 lazygit 定位相近但取捨相反，刻意保持精簡並換取效能。日常的 stage、commit、branch、stash、blame、log 都涵蓋，但進階流程的覆蓋度不追求面面俱到。它跟 lazygit 的深入比較放在後面一節。

純 log 線圖增強（走管線、零 TUI）

這類工具不開全螢幕介面，而是改善 git log 一次性輸出的可讀性，責任是讓線圖更清楚、讓 diff 配色更易讀。它走標準輸出與管線，適合接在腳本裡或當成 alias 隨手用。

git log --graph 系列（也就是 glog / gloga）是這條路線的起點，零安裝、處處可用。git-graph 是專門產生比內建更清楚的 ASCII 分支線的工具，當內建線圖在複雜合併歷史下變得難讀時，它把分支著色與排版做得更工整。delta 是 diff 的語法高亮 pager，嚴格說不算線圖工具，但它把 git log -p 與 git diff 的輸出做成帶配色、帶行號、可左右並排的版面，常跟前述工具搭配使用 — 後面 lazygit 的 side-by-side diff 就是靠它。

這類工具的判讀訊號是：需要的是「印一次看一眼」而非持續導航。它對頻寬特別友善，因為是一次性輸出、不像 TUI 會持續重畫畫面。

桌面 GUI（遠端通常排除）

gitk、git-gui、gitg 這類桌面圖形工具依賴 X11 或桌面環境，在純終端機的遠端連線下無法直接執行，或需要繁瑣且吃頻寬的 X11 forwarding。這個排除有明確前提：本篇限定「只有終端機、不能在遠端裝 IDE agent」的最小情境。若情境允許 IDE 的 remote 機制（VS Code Remote-SSH、JetBrains Gateway）或可接受 X11 forwarding，桌面 GUI 仍能遠端使用、體驗也不差 — 這條前提放寬時，本篇的結論會跟著變。把 GUI 列在這裡只為說明邊界：它們解決的是「有桌面或 IDE 通道」的需求，與「只有終端機」是不同場景。

遠端情境為什麼偏好單一 binary

遠端開發選型有一個容易被忽略的隱性約束：工具的安裝依賴。Go 與 Rust 寫的工具（lazygit、gitui、git-graph、delta）通常編譯成單一 binary，相較需要先裝 runtime 的工具，把檔案搬上去就能用，這是它們在 SSH 情境特別受歡迎的原因之一。

但「單一 binary」要打兩個折扣，照字面 scp 可能撞牆。其一，binary 自身不含 runtime，不代表沒有執行期依賴：lazygit 與 gitui 執行時都會呼叫系統的 git，遠端機沒裝 git 就跑不動。其二，Rust 工具（gitui / delta）預設動態連結 glibc，不是真正的 static；跨發行版或搬進 alpine 容器（用 musl）會出現 GLIBC not found，這種情境要下載對應的 musl 靜態建置版。判讀的分界是：能用系統套件管理器自由安裝時，依語言寫成什麼影響不大；環境受限時，除了「一個檔案」還要確認目標機有 git、且 binary 的 libc 對得上目標系統。這也是為什麼 git log --graph alias 是最後的保命符 — 它連 binary 都不必搬。

lazygit 與 gitui 的定位差異

lazygit 與 gitui 表面功能重疊度很高，選擇依據主要落在以下幾個面向，而非單純「誰比較快」。

技術底色：效能與資源

gitui 用 Rust 做了非同步架構，在 monorepo、歷史很長、或機器資源有限（老舊伺服器、容器內）時反應更跟手，啟動極快、記憶體佔用低。lazygit 的效能日常夠用，但在 diff 或 log 非常大時偶有卡頓、記憶體佔用較高。這是兩者最常被提到的分水嶺，也直接對應遠端機器的強弱。

功能廣度 vs 功能聚焦

這是比效能更根本的定位差異。lazygit 賭功能廣度：互動式 rebase、cherry-pick、stash 管理、衝突解決、自訂指令幾乎都包了，目標是讓人完全不打 git 指令。gitui 賭功能聚焦：涵蓋 stage、commit、branch、stash、blame、log 這些日常約八成的操作，進階流程（複雜 rebase）的覆蓋度刻意保留，設計上傾向不做太重的事。

選型決策邏輯

兩者背後是兩種不同的使用意圖。傾向 lazygit 的，是想用一個工具取代 git CLI、把版控操作整碗端進終端機，願意付稍高的資源代價換廣度與便利。傾向 gitui 的，是想要一個快速的 git 視窗，主要看狀態、看歷史、做基本提交，要求即開即用、進階操作仍回去打 git 指令。一句話收斂：lazygit 押廣度與便利，gitui 押速度與輕量。

生態與社群

lazygit 社群採用度較高、star 數較多、教學與設定檔分享資源豐富，keybinding 與自訂指令的客製空間大。gitui 社群較小但穩定，定位清晰。對需要大量客製或想參考他人設定的情境，lazygit 的生態是實質優勢。長期依賴前也值得瞄一眼維護活躍度（release 節奏決定 bug 修復速度）— 兩者都在活躍維護，但 star 數高不等於修得快，這跟社群熱度是兩件事。

選型判準（遠端 CLI 情境）

把上述收斂成一條判準鏈，對應遠端開發的機器條件：

• 機器資源充足、想要一個工具搞定所有 git 操作：選 lazygit，把它當操作中樞。
• 遠端機器較弱、repo 很大、或只想快速看狀態做提交：選 gitui，換取即開即用與低資源。粗略 tripwire：repo 歷史上萬筆 / monorepo、機器 RAM 約 1GB 以下、或 lazygit 開大 diff 時明顯卡頓，就往 gitui 靠。
• 只需要看歷史與 diff、不在工具裡做版控操作：tig 的唯讀定位最輕量。
• 環境受限、不能安裝：退回 gloga（git log --graph --all），它在任何 git 環境都成立。

這四者能共存。常見的搭配是 tig 看歷史 + lazygit 做操作，兩者互補性高；gitui 與 tig 的瀏覽定位略有重疊，同時留兩個的理由較弱。風險與邊界在於學習成本：操作中樞型工具按一個鍵就改動 repo，初期適合先在拋棄式分支或測試 repo 練手，熟悉後再用到開發分支。

lazygit 上手與 side-by-side diff

lazygit 的介面遵循一個固定心法：左側面板選「對什麼東西操作」、右側看「內容」、底部提示列顯示「當前能按什麼」。底部提示列會隨游標位置動態變化，所以操作不必背全部快捷鍵，迷路時按 ? 會叫出當前面板的上下文敏感說明。

入門只需記幾個導航鍵：Tab 或數字 1~5 切換左側面板（Status / Files / Branches / Commits / Stash），方向鍵或 hjkl 在面板與清單內移動，Esc 返回上一層，q 離開。線圖在 Commits 面板（按 4），全分支關係在 Branches 面板（按 3）。三個最常用的日常操作：在 Files 面板用空白鍵 stage / unstage、stage 完按 c 輸入訊息提交、在 Commits 面板選 commit 後右側自動顯示 diff（Enter 進入檔案層級）。

預設的 diff 是單欄 unified（增刪行逐行上下排列）呈現。要做到像 IDE 那樣左右並排（side-by-side）對齊，lazygit 本身沒有內建這個視圖，需要外接 pager。pager 是負責把長輸出分頁、上色顯示的程式（git 預設用 less）；這裡讓 lazygit 把 diff 文字交給外部 pager 上色並重排成並排版面，最常見的搭配是 delta。安裝 delta 後，在 lazygit 設定檔（~/Library/Application Support/lazygit/config.yml，或 ~/.config/lazygit/config.yml）指定它當 pager 並開啟並排模式：

1git:
2  pagers:
3    - colorArg: always
4      pager: delta --dark --paging=never --side-by-side

--side-by-side 是讓 delta 左右並排的關鍵旗標，--paging=never 讓 delta 只負責上色與排版、捲動分頁仍由 lazygit 處理。git.pagers（list）是現行 lazygit 的設定鍵；舊版的 git.paging.pager（單數）仍可用，新版啟動時會自動 migrate 成上面的形式並改寫設定檔。在窄螢幕（手機、平板遠端）下，並排會把每欄壓得很窄，這種情境改回垂直單欄反而好讀 — side-by-side 的適用條件是螢幕夠寬。

下一步路由

選型確定後，後續深入的方向：

• 想完全用鍵盤取代 git 指令：深入 lazygit 的互動式 rebase、cherry-pick 與自訂指令流程。
• 遠端機器資源吃緊：實測 gitui 在大型 repo 的反應，跟 lazygit 同一個 repo 跑一次比較體感。
• diff 配色與並排需求延伸到日常 git：把 delta 設成 git 全域 pager（git config --global core.pager delta），讓 git diff 與 git log -p 也吃到同一套配色。

git 線圖在整個遠端 CLI 工具選型中的位置，見 終端機圖形化工具總覽 — 本篇屬其中的版控子題、與系統監控的 TUI 工具脈絡相承。

安裝 Zellij

1# macOS
2brew install zellij
3
4# Linux（使用安裝腳本）
5bash <(curl -L zellij.dev/launch)
6
7# Windows（需要支援原生 Windows 的版本，詳見 GitHub Releases）
8# 從 https://github.com/zellij-org/zellij/releases 下載 Windows 版 .zip
9# 解壓後將 zellij.exe 加入 PATH

確認版本（需 v0.43.0 以上）：

1zellij --version

事前準備

• 一個網域名稱（或固定 IP）
• SSL 憑證（對外連線強制要求）
• SSH 連線能力（如需遠端操作主機）→ 參考 SSH Key 設定筆記

步驟一：取得 SSL 憑證

外網連線強制使用 HTTPS，必須提供 SSL 憑證。

取得 Let’s Encrypt 憑證的 certbot 指令需真實網域、本機未實機驗證；自簽憑證的 openssl 指令、以及 zellij web server 啟停與 token 管理已在 localhost 實機驗證。

使用 Let’s Encrypt（免費，推薦）

需要先安裝 certbot：

1# macOS
2brew install certbot
3
4# Ubuntu / Debian
5sudo apt install certbot
6
7# Windows（使用 Chocolatey）
8choco install certbot
9# 或使用 win-acme（Windows 原生替代方案）：https://www.win-acme.com/

申請憑證（將 your-domain.com 換成實際網域）：

1sudo certbot certonly --standalone -d your-domain.com

Windows 上若未使用 WSL，建議改用 win-acme，操作更直覺。

憑證預設存放在：

1# macOS / Linux
2/etc/letsencrypt/live/your-domain.com/fullchain.pem   # 憑證
3/etc/letsencrypt/live/your-domain.com/privkey.pem      # 私鑰
4
5# Windows（certbot）
6C:\Certbot\live\your-domain.com\fullchain.pem
7C:\Certbot\live\your-domain.com\privkey.pem

使用自簽憑證（測試用）

1openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

注意：自簽憑證會讓瀏覽器在連線時顯示安全警告，於測試環境手動選擇繼續即可；正式對外服務改用上面的 Let’s Encrypt 憑證。

步驟二：開放防火牆 Port

Zellij web server 預設只綁本機 127.0.0.1:8082，要讓外網連入必須顯式綁到對外位址（見步驟四的 --ip 0.0.0.0）並開放對應 port。本教學以 port 3000 為例（port 可自選），需對外開放這個 port：

以下防火牆指令（ufw / pf / Windows Defender）依各平台官方用法、環境特定、本機未實機驗證。

Linux（ufw）

1sudo ufw allow 3000/tcp
2
3# 或指定來源 IP（更安全）
4sudo ufw allow from 1.2.3.4 to any port 3000

macOS

macOS 內建的防火牆是應用程式層級的，無法直接開放特定 port。通常有兩種做法：

1. 系統偏好設定 → 網路 → 防火牆 → 確認沒有擋住 Zellij
2. 使用 pf（進階，通常不需要）：

1# 新增規則到 /etc/pf.conf
2echo "pass in proto tcp from any to any port 3000" | sudo tee -a /etc/pf.conf
3sudo pfctl -f /etc/pf.conf

macOS 預設防火牆通常不會擋住主動開啟的服務，多數情況下不需要額外設定。如果是在家用網路，記得在路由器設定 port forwarding。

Windows

1# 使用 Windows Defender Firewall（以系統管理員執行 PowerShell）
2New-NetFirewallRule -DisplayName "Zellij Web" -Direction Inbound -Protocol TCP -LocalPort 3000 -Action Allow
3
4# 或限制來源 IP（更安全）
5New-NetFirewallRule -DisplayName "Zellij Web" -Direction Inbound -Protocol TCP -LocalPort 3000 -RemoteAddress 1.2.3.4 -Action Allow

Zellij 已支援原生 Windows，直接在 PowerShell 或 Windows Terminal 中執行即可。

如果是雲端主機（AWS、GCP、Azure 等），記得同步在後台的安全群組開放 port 3000。

步驟三：啟動 Zellij

先啟動一個 Zellij session：

1zellij

步驟四：啟動 Web Server

在 Zellij 內，按 Ctrl+o 然後按 s 開啟 share plugin，從 UI 啟動 web server。

或直接用 CLI 啟動並指定憑證：

1zellij web \
2  --ip 0.0.0.0 --port 3000 \
3  --cert /etc/letsencrypt/live/your-domain.com/fullchain.pem \
4  --key /etc/letsencrypt/live/your-domain.com/privkey.pem

背景執行（daemon 模式）：

1zellij web -d \
2  --ip 0.0.0.0 --port 3000 \
3  --cert /path/to/cert.pem \
4  --key /path/to/key.pem

停止 web server：

1zellij web --stop

確認 web server 執行狀態：

1zellij web --status

Zellij web 預設綁 127.0.0.1:8082、只接受本機連線；對外服務必須用 --ip 0.0.0.0 顯式綁到對外位址、並用 --port 指定埠（本教學用 3000）。改用其他 port 時把 --port 一併調整（例如 --port 8443），防火牆規則也要同步改成該 port。

步驟五：產生登入 Token

為了安全，別人連線前需要用 token 登入，token 只會顯示一次，請立即複製。

1zellij web --create-token

或在 share plugin（Ctrl+o + s）裡產生。

將 token 分享給要連線的人。

步驟六：連線

對方在瀏覽器輸入：

1https://your-domain.com:3000/實際-session-名稱

首次連線會要求輸入 token，驗證後即可進入 session。若連線後畫面沒有回應，多半是 port 未對外開放，確認防火牆與雲端主機安全群組是否放行該 port。

連線後的行為

多人連線時，每個人都有自己的游標，可以同時操作。

安全建議

• Token 用完後記得撤銷：從 share plugin 或 CLI 管理
• 盡量限制開放的來源 IP，避免對全網開放
• 不建議長期開啟 web server，用完就關
• 撤銷 token 時，所有對應的 session token 也會一併失效

下一步路由

• zellij 的本機 pane 操作（查看佈局、讀取其他 pane、調整大小）：Zellij 多終端機操作指南。
• 不需要瀏覽器、純 SSH 的多工器持久化：tmux 基礎。
• 多工器在整個遠端工具選型中的定位：終端機圖形化工具總覽。

查看整體佈局

1zellij action dump-layout

會輸出完整的 KDL 格式佈局，包含所有 pane 的大小、位置、指令等資訊。

讀取其他終端機 pane 的內容

Claude 無法直接看到螢幕，但可以透過以下步驟讀取其他 pane 的輸出：

 1# 1. 切換 focus 到目標 pane（focus-next-pane 會依序切換）
 2# 2. dump 該 pane 的螢幕內容到檔案
 3# 3. 切回原本的 pane
 4# 4. 讀取 dump 的檔案
 5
 6zellij action focus-next-pane && \
 7zellij action focus-next-pane && \
 8zellij action dump-screen /tmp/zellij-pane-output.txt && \
 9zellij action focus-previous-pane && \
10zellij action focus-previous-pane

• dump-screen 只 dump 當前可見的內容
• dump-screen -f 會包含完整的 scrollback 歷史
• 切換次數取決於目標 pane 的位置，需根據 dump-layout 的結果判斷

調整 pane 大小

1# 縮小當前 pane（向左縮）
2zellij action resize decrease right
3
4# 放大當前 pane（向右擴）
5zellij action resize increase right
6
7# 每次約改變 ~4-5% 寬度，可用迴圈批次調整
8for i in $(seq 1 3); do zellij action resize decrease right; done

每次的步長是經驗值、不是固定比例 — zellij 的 resize 幅度依版本與 pane 當前尺寸而定，迴圈次數需視 dump-layout 的結果微調。

使用者的 Resize 快捷鍵

1. Ctrl + n 進入 Resize 模式
2. h/l 或方向鍵調整大小
3. Esc 退出

注意：在 Claude 互動式程式內，快捷鍵可能被吃掉，建議讓 Claude 用指令操作。

注意事項

• Ctrl + p 進入 Pane 模式，其中 r 用於在右邊新開 pane（調整大小是 Ctrl + n 的 Resize 模式）
• 使用者的典型佈局：左側 Claude（~35%），右側上下兩個終端機

下一步路由

• 把 session 分享給沒有 SSH 連線的協作者（瀏覽器連入）：Zellij Web Client 外網連線教學。
• 純 SSH 的多工器持久化與 tmux 對照：tmux 基礎。
• 多工器在遠端工具選型中的定位：終端機圖形化工具總覽。