日常指令的現代替代品

• 現代 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 管理 的終端機與編輯器模組。

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

本文承接 終端機圖形化工具總覽 的訊息佇列客戶端分類。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 基礎。
• 訊息佇列客戶端在遠端工具分類中的定位：終端機圖形化工具總覽。

本文承接 終端機圖形化工具總覽 的 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 工具脈絡，屬監控的 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 工具脈絡相承。