大家都說(shuō) Homebrew 是 macOS 上最值得裝的包管理器這句話(huà)我到現(xiàn)在都認(rèn)但有個(gè)前提它默認(rèn)只給“愿意在終端里敲命令的人”提供服務(wù)。我自己天天 brew install、brew upgrade沒(méi)覺(jué)得哪里不方便直到有一次幫朋友配開(kāi)發(fā)環(huán)境她看著我打開(kāi)終端滿(mǎn)屏的brew install node、brew install git第一反應(yīng)是“以后每次更新我都要背這些命令嗎”。那一刻我突然意識(shí)到Homebrew 本身沒(méi)有錯(cuò)錯(cuò)的可能是交互層。于是我用幾個(gè)周末做了個(gè)小工具名字就叫 BrewUI給 Homebrew 套一層圖形界面把安裝、卸載、升級(jí)、清理緩存、看依賴(lài)關(guān)系這些高頻操作全部變成按鈕和面板。這篇文章就把 BrewUI 從選型、架構(gòu)、核心功能到實(shí)際開(kāi)發(fā)中踩過(guò)的坑完整拆一遍給想做同類(lèi)工具或者正在折騰 Homebrew 自動(dòng)化的人一個(gè)參考。我一直覺(jué)得一個(gè)好的工具不該把用戶(hù)擋在終端外面。BrewUI 的目標(biāo)也很簡(jiǎn)單五分鐘內(nèi)讓一個(gè)很少碰終端的開(kāi)發(fā)者也敢自己維護(hù)開(kāi)發(fā)環(huán)境同時(shí)保留日志面板讓老手仍然能看到 Homebrew 底層到底在干什么。1. 命令行很好但為什么我還是做了 BrewUI1.1 一個(gè)被終端勸退的真實(shí)場(chǎng)景先說(shuō)最直接的原因。我認(rèn)識(shí)不少后端、前端做得不錯(cuò)的人日常在 IDE 里寫(xiě)代碼沒(méi)問(wèn)題可一旦要他們打開(kāi) macOS 自帶的 Terminal整個(gè)人的狀態(tài)就會(huì)緊張。一次我?guī)屯卵b protobuf 編譯器給了他三條命令讓他自己敲。十分鐘后他截圖過(guò)來(lái)報(bào)錯(cuò)信息是zsh: command not found: brew因?yàn)樗麚Q了一臺(tái)新電腦Homebrew 本身還沒(méi)裝。于是又得先引導(dǎo)他裝 Homebrew再處理環(huán)境變量 PATH。整個(gè)過(guò)程因?yàn)椤皩?duì)終端不熟”每一步都變得很沉重。這就是我想做 BrewUI 的第一個(gè)動(dòng)機(jī)工具鏈本身不該成為門(mén)檻。Homebrew 更新軟件、卸載軟件、清理舊版本本質(zhì)上都不需要用戶(hù)理解“命令是如何被 shell 解釋的”它們只是一些確定性的操作。把這些操作圖形化是降低學(xué)習(xí)成本最直接的方式。1.2 當(dāng)我的包列表膨脹到幾百個(gè)以后等我自己管理的 formula 和 cask 加起來(lái)超過(guò)三百個(gè)命令行其實(shí)也沒(méi)那么舒服了。舉幾個(gè)我日常會(huì)遇到的場(chǎng)景brew list輸出一長(zhǎng)屏我想知道哪個(gè)包最大根本看不出來(lái)。想升級(jí)某個(gè)包但不知道它的依賴(lài)會(huì)被連帶升級(jí)到什么程度得先敲brew info看依賴(lài)關(guān)系。磁盤(pán)告急時(shí)想清理brew cleanup不敢直接執(zhí)行怕把不該刪的刪了只能先--dry-run預(yù)覽但輸出也是一坨文本。某些包已經(jīng)不被依賴(lài)了成了孤兒包我得用brew leaves和brew deps組合起來(lái)推費(fèi)力。這些不是 Homebrew 本身的設(shè)計(jì)缺陷而是命令行交互的天然局限。它適合腳本化適合管道處理但不適合給人做“快速?zèng)Q策”。BrewUI 想解決的就是這個(gè)信息密度問(wèn)題把包列表變成可搜索、可排序、可看詳情的表格把依賴(lài)關(guān)系變成樹(shù)把磁盤(pán)占用變成條形圖把清理動(dòng)作變成“先預(yù)覽再確認(rèn)”。1.3 市面上的 Homebrew GUI 為什么不夠用決定自己做之前我當(dāng)然也把現(xiàn)有方案翻了一圈比如 Cakebrew 和其他幾個(gè)零散的開(kāi)源項(xiàng)目。方向現(xiàn)有工具給我的體感與 BrewUI 的差距Cakebrew界面老較長(zhǎng)時(shí)間沒(méi)大版本更新只讀信息多操作能力弱對(duì) Cask 支持不完整部分 Homebrew GUI 小工具功能單一很多只做列表展示安裝/卸載/依賴(lài)/清理一體化的幾乎沒(méi)有命令行別名 / 腳本靈活但只幫到會(huì)寫(xiě)腳本的人不能解決“可視化決策”的問(wèn)題另外還有一個(gè)很現(xiàn)實(shí)的原因這些項(xiàng)目大多沒(méi)有專(zhuān)門(mén)做“操作安全”。Homebrew 的升級(jí)、清理都是有副作用的動(dòng)作界面工具如果只是簡(jiǎn)單地把命令拼出來(lái)丟給 shell很容易出現(xiàn)“用戶(hù)點(diǎn)錯(cuò)按鈕把一堆包升到不兼容版本”的問(wèn)題。BrewUI 從一開(kāi)始就把“操作前預(yù)覽、操作后反饋”當(dāng)成核心設(shè)計(jì)不是簡(jiǎn)單套一層 GUI。1.4 BrewUI 的定位不是替代終端而是補(bǔ)上交互層我給自己定的產(chǎn)品邊界很清楚BrewUI 不追求替代命令行。它只做 Homebrew 這一件事而且優(yōu)先把高頻、高風(fēng)險(xiǎn)、需要信息展示的動(dòng)作做好。具體拆下來(lái)就是四個(gè)主面板包管理瀏覽、搜索、安裝、卸載、升級(jí)Formulae 和 Cask 分流展示。檢查更新一鍵檢查 outdated 列表按包名、倉(cāng)庫(kù)、依賴(lài)數(shù)量排序選擇性地升級(jí)。依賴(lài)可視化以某個(gè)包為中心展示它依賴(lài)了什么又被誰(shuí)依賴(lài)。緩存與磁盤(pán)分析 Cellar、Caskroom、Homebrew 緩存占用預(yù)覽可清理內(nèi)容再執(zhí)行清理。這條邊界非常重要。一個(gè)工具如果什么都要管最后多半什么都做不精。BrewUI 只對(duì) Homebrew 負(fù)責(zé)這也讓它在實(shí)現(xiàn)上可以做得非常聚焦。2. 技術(shù)底座為什么是 Tauri以及命令層怎么設(shè)計(jì)2.1 桌面框架選型對(duì)比BrewUI 是一個(gè)桌面應(yīng)用需要常駐菜單欄或者以窗口形式存在啟動(dòng)要快內(nèi)存不能太夸張。我在 Electron、Tauri、原生 Swift 之間對(duì)比了一輪。框架安裝包體積內(nèi)存占用前端生態(tài)開(kāi)發(fā)門(mén)檻跨平臺(tái)Electron100MB 起步通常 200MB極好低Win/macOS/LinuxTauri5-10MB30-60MB好需要 Rust 基礎(chǔ)Win/macOS/Linux原生 SwiftUI極小極低受限于 Apple 生態(tài)高僅 Apple 平臺(tái)還有一個(gè)關(guān)鍵點(diǎn)BrewUI 的核心業(yè)務(wù)是“調(diào)用 Homebrew 命令并解析輸出”這正好適合放在一個(gè)強(qiáng)類(lèi)型的后端語(yǔ)言里處理而不是每個(gè)命令都拿 String 在 JS 層拼接。Tauri 的 Rust 后端天然適合做這件事所以我最終選了 Tauri Vue 3 TypeScript。Rust 不算很好上手但它的錯(cuò)誤處理、進(jìn)程管理、性能表現(xiàn)在這個(gè)場(chǎng)景里非常劃算。2.2 整體架構(gòu)一條命令從前端到 Homebrew 的路徑BrewUI 的調(diào)用鏈路大致是這樣的Vue 3 界面 ↓ tauri invokeJSON 參數(shù) Rust Command 層解析參數(shù)、構(gòu)造命令、設(shè)置環(huán)境變量 ↓ std::process::Command Homebrew CLIbrew install / upgrade / cleanup ... ↓ stdout / stderr 流 Rust 事件層清理 ANSI 轉(zhuǎn)義、按行解析 ↓ tauri event 前端日志面板 / 狀態(tài)更新這里面最核心的設(shè)計(jì)決策是前端永遠(yuǎn)不直接拼命令字符串。所有 brew 命令的參數(shù)都在 Rust 端通過(guò)Command::new(brew).args([...])構(gòu)造。這樣有兩個(gè)好處一是避免前端輸入被當(dāng)作 shell 命令解釋二是命令的構(gòu)造邏輯收斂在同一個(gè)模塊里以后 Homebrew 參數(shù)變化只需要改 Rust 端一個(gè)函數(shù)。2.3 為什么沒(méi)有直接用 Node 的 child_processElectron 里也能用child_process.exec直接跑 brew那為什么還要在 Rust 里包一層因?yàn)槲倚枰幚淼牟恢皇恰芭芤粭l命令然后拿結(jié)果”還有這些復(fù)雜情況命令執(zhí)行過(guò)程中需要流式輸出日志用戶(hù)要實(shí)時(shí)看到進(jìn)度。用戶(hù)可能取消操作Rust 端需要可靠地殺死子進(jìn)程。brew 命令之間不能并發(fā)執(zhí)行否則會(huì)撞 Homebrew 自己的鎖Rust 端可以做一個(gè)全局任務(wù)隊(duì)列。升級(jí)和清理是有副作用的操作需要命令層的統(tǒng)一“確認(rèn)”和“預(yù)覽”機(jī)制。Rust 的std::process::Command對(duì)子進(jìn)程的控制能力很強(qiáng)加上 Tauri 的 command 機(jī)制可以很方便地把數(shù)據(jù)從后端推到前端。相比 Node 的 child_processRust 的表達(dá)力稍陡峭但換來(lái)的是更可控的進(jìn)程生命周期。2.4 數(shù)據(jù)模型與緩存策略Homebrew 本身提供了非常規(guī)整的 JSON 輸出接口brew info --jsonv2會(huì)返回一個(gè)包含 name、desc、versions、installed、dependencies 等字段的大型 JSON 結(jié)構(gòu)。BrewUI 把所有已安裝包的信息拉下來(lái)之后會(huì)解析成一個(gè)內(nèi)部結(jié)構(gòu)。#[derive(Deserialize)] struct BrewInfo { name: String, desc: OptionString, versions: Versions, installed: VecInstalled, dependencies: VecString, build_dependencies: VecString, #[serde(default)] outdated: bool, } #[derive(Deserialize)] struct Installed { version: String, #[serde(default)] installed_on_request: bool, #[serde(default)] runtime_dependencies: VecRuntimeDep, }解析完成后我會(huì)把結(jié)果緩存到本地 SQLite。為什么不每次都重新跑brew info因?yàn)橐粋€(gè)開(kāi)發(fā)機(jī)上裝了幾百個(gè)包時(shí)全量 info 要好幾秒而且很沒(méi)必要。BrewUI 的啟動(dòng)策略是首次啟動(dòng)后臺(tái)跑一次全量 info拉完寫(xiě)緩存。之后啟動(dòng)先讀緩存立即渲染同時(shí)靜默刷新一次有變化再更新界面。用戶(hù)主動(dòng)點(diǎn)“檢查更新”時(shí)才跑brew outdated --json這個(gè)命令比全量 info 輕量。緩存里不僅要存 JSON 原始數(shù)據(jù)還要記錄“上次成功刷新時(shí)間”。這樣即使 Homebrew 暫時(shí)不可用BrewUI 也能正常展示上一次的數(shù)據(jù)而不是白屏或者一直轉(zhuǎn)圈。3. 核心功能拆解包列表、操作封裝與依賴(lài)可視化3.1 包列表把 Formulae 和 Cask 分開(kāi)是必須的Homebrew 有兩類(lèi)包Formulae 和 Cask。前者是命令行工具和庫(kù)后者是圖形應(yīng)用。它們的更新的確都走 Homebrew但用戶(hù)心智完全不同。BrewUI 的主界面分兩個(gè)頁(yè)簽Formula 頁(yè)簽展示命令行工具比如 git、node、python。Cask 頁(yè)簽展示圖形應(yīng)用比如 Visual Studio Code、Google Chrome。為什么必須分開(kāi)因?yàn)椴僮鲝?fù)雜度不一樣。Formula 的安裝、卸載、升級(jí)通常不需要管理員權(quán)限干凈利落Cask 安裝的包可能會(huì)寫(xiě)入 /Applications有些還是帶安裝器的 pkg執(zhí)行時(shí)可能觸發(fā)密碼彈窗。如果不分開(kāi)用戶(hù)會(huì)困惑“為什么裝一個(gè)軟件還要輸入密碼”。列表本身需要做到支持本地模糊搜索比如輸入 “py” 能匹配 python。支持按體積排序體積數(shù)據(jù)來(lái)自后臺(tái)對(duì) Cellar/Caskroom 目錄的du統(tǒng)計(jì)。支持按更新時(shí)間、依賴(lài)數(shù)量排序。雙擊某個(gè)包右側(cè)抽屜展示 desc、版本、依賴(lài)、依賴(lài)它的包、安裝路徑。這里有個(gè)容易忽略的點(diǎn)brew list的輸出是不含包描述的而描述在brew info --jsonv2里。如果只讀列表界面上全是包名新手根本不知道怎么選。BrewUI 會(huì)把 desc 字段映射到列表子行一句話(huà)說(shuō)明這個(gè)包是干什么的。3.2 安裝、卸載、更新操作怎么封裝成可靠任務(wù)點(diǎn)按鈕執(zhí)行 brew 命令是最表面的一層真正麻煩的是“操作生命周期管理”。BrewUI 把每一次操作抽象成 TaskTask 的狀態(tài)包括queued排隊(duì)中因?yàn)橥粫r(shí)間只允許一個(gè) brew 任務(wù)執(zhí)行。running正在執(zhí)行日志流持續(xù)追加。canceled用戶(hù)取消。success / failed最終結(jié)果。任務(wù)執(zhí)行時(shí)的核心邏輯是#[tauri::command] async fn run_brew_task( app: AppHandle, args: VecString, cancel_flag: ArcAtomicBool, ) - ResultTaskResult, String { let mut cmd Command::new(brew); cmd.args(args) .env(HOMEBREW_NO_AUTO_UPDATE, 1) .env(HOMEBREW_NO_INSTALL_CLEANUP, 1) .stdout(Stdio::piped()) .stderr(Stdio::piped()) .kill_on_drop(true); // 關(guān)鍵防止命令泄漏到后臺(tái) let mut child cmd.spawn().map_err(|e| e.to_string())?; let stdout child.stdout.take().unwrap(); let reader BufReader::new(stdout); for line in reader.lines() { if cancel_flag.load(Ordering::Relaxed) { child.kill()?; break; } let clean_line strip_ansi_escapes::strip_str(line?); app.emit(brew://log, clean_line)?; } let status child.wait().await?; Ok(TaskResult { code: status.code() }) }這里面有幾個(gè)細(xì)節(jié)值得展開(kāi)。第一HOMEBREW_NO_AUTO_UPDATE1必須設(shè)置。Homebrew 默認(rèn)在 install/upgrade 前可能自動(dòng)更新自己一旦觸發(fā)界面會(huì)卡在 “Updating Homebrew…” 很長(zhǎng)時(shí)間用戶(hù)完全不知道發(fā)生了什么。BrewUI 把“更新 Homebrew 本身”拆成單獨(dú)的按鈕而不是讓它在后臺(tái)隱式發(fā)生。第二流式日志處理。Rust 端逐行讀取子進(jìn)程輸出通過(guò) Tauri event 推送前端。日志在傳到前端前還要做一次 ANSI 轉(zhuǎn)義碼清理否則界面上會(huì)看到一堆[32m、[0m這樣的控制字符。第三任務(wù)不能并發(fā)。Homebrew 對(duì)并發(fā)的容忍度很低兩個(gè) brew 進(jìn)程同時(shí)跑會(huì)互相等待鎖文件極端情況下還會(huì)報(bào)錯(cuò)。BrewUI 用前端全局任務(wù)隊(duì)列保證同一時(shí)間只有一個(gè) Task running其余按鈕全部置灰。卸載、升級(jí)在命令層的差別只是參數(shù)不同卸載brew uninstall --formula name升級(jí)單個(gè)包brew upgrade name升級(jí)全部brew upgrade不推薦在 GUI 里做全量升級(jí)原因后面說(shuō)每個(gè)操作在執(zhí)行前BrewUI 都要求用戶(hù)點(diǎn)一次確認(rèn)并且確認(rèn)彈窗里會(huì)寫(xiě)明“這個(gè)操作將影響以下包和它們的依賴(lài)”。升級(jí)單個(gè)包前還會(huì)展示它的依賴(lài)樹(shù)變化避免用戶(hù)點(diǎn)完按鈕才發(fā)現(xiàn)連帶了二三十個(gè)依賴(lài)。3.3 依賴(lài)可視化不只是一張漂亮的圖依賴(lài)關(guān)系是 Homebrew GUI 工具最容易做砸的部分。很多人拿brew deps --tree的輸出渲染一張樹(shù)圖但實(shí)際開(kāi)發(fā)機(jī)上包與包之間的依賴(lài)是網(wǎng)狀結(jié)構(gòu)純樹(shù)形表示會(huì)丟失信息。BrewUI 的做法是不使用brew deps --tree的文本輸出而是基于brew info --jsonv2里的dependencies和runtime_dependencies字段自己構(gòu)建一個(gè)有向圖。構(gòu)建過(guò)程中有兩個(gè)關(guān)鍵點(diǎn)一是環(huán)檢測(cè)。包 A 依賴(lài) BB 也可能依賴(lài) A如果直接遞歸展開(kāi)前端就爆棧了。BrewUI 維護(hù)一個(gè)visiting集合遇到已經(jīng)出現(xiàn)在當(dāng)前路徑上的節(jié)點(diǎn)就標(biāo)記為“循環(huán)依賴(lài)”并在圖中單獨(dú)標(biāo)紅。二是深度控制。默認(rèn)只展開(kāi)選中包的完整依賴(lài)鏈但同一層節(jié)點(diǎn)數(shù)量太多時(shí)自動(dòng)折疊為“N 個(gè)直接依賴(lài)”用戶(hù)需要手動(dòng)展開(kāi)。這樣避免一次渲染幾百個(gè)節(jié)點(diǎn)導(dǎo)致界面卡死。前端我選了 D3.js 的力導(dǎo)向布局。節(jié)點(diǎn)顏色表達(dá)狀態(tài)綠色正常且已是最新版本。橙色有更新可用。紅色存在異常比如依賴(lài)循環(huán)、版本沖突。用戶(hù)點(diǎn)擊任意節(jié)點(diǎn)可以繼續(xù)以那個(gè)包為中心重新生成一張局部圖。這是一種“按需擴(kuò)展”的思路比一次性展示全量依賴(lài)更實(shí)用。3.4 磁盤(pán)占用與緩存清理磁盤(pán)清理不能一上來(lái)就brew cleanup。BrewUI 走了“分析 → 預(yù)覽 → 確認(rèn) → 執(zhí)行”的流程。分析階段后臺(tái)會(huì)對(duì)這些目錄做磁盤(pán)占用統(tǒng)計(jì)目錄路徑作用$(brew --prefix)/CellarFormula 安裝目錄舊版本殘留主要在這$(brew --prefix)/CaskroomCask 安裝目錄~/Library/Caches/Homebrew下載緩存包含 .tar.gz、.zip 等~/Library/Caches/Homebrew/downloads具體下載文件緩存統(tǒng)計(jì)時(shí)不會(huì)在 Rust 里遞歸遍歷每個(gè)文件那樣太慢而是直接調(diào)du -sh這個(gè)系統(tǒng)命令幾毫秒就能拿到總量。預(yù)覽階段BrewUI 會(huì)并行執(zhí)行brew cleanup --dry-run列出可清理的舊版本 formula。brew autoremove --dry-run列出不再被依賴(lài)的孤兒包。然后把兩項(xiàng)結(jié)果匯總成一張“可釋放空間估算”卡片用戶(hù)能清楚看到執(zhí)行后會(huì)刪哪些東西。確認(rèn)后才會(huì)執(zhí)行真正的brew cleanup和brew autoremove并且把輸出日志回顯到面板。4. 排查記錄BrewUI 開(kāi)發(fā)中繞不開(kāi)的四個(gè)坑4.1 第一個(gè)坑brew 命令自己先跑去 update任務(wù)半天不結(jié)束B(niǎo)rewUI 最早版本剛跑通時(shí)我點(diǎn)了一下安裝按鈕日志窗口里停留了很久“Updating Homebrew...”看起來(lái)就像卡死了一樣。那其實(shí)不是卡死是 Homebrew 的默認(rèn)行為很多命令在開(kāi)始前會(huì)嘗試把 Homebrew 倉(cāng)庫(kù)更新到最新如果網(wǎng)絡(luò)下載慢這個(gè)過(guò)程會(huì)非常長(zhǎng)。這個(gè)問(wèn)題說(shuō)到底是我沒(méi)有顯式控制 Homebrew 的運(yùn)行環(huán)境。修復(fù)方案就是前面提到的在每次調(diào)用 brew 之前設(shè)置環(huán)境變量.env(HOMEBREW_NO_AUTO_UPDATE, 1)同時(shí)BrewUI 把“更新 Homebrew 本體”放到了工具欄上單獨(dú)一個(gè)按鈕需要的時(shí)候手動(dòng)觸發(fā)。這樣用戶(hù)的操作意圖就很明確了我點(diǎn)安裝就是安裝不要背著我去做別的事。4.2 第二個(gè)坑解析日志時(shí)滿(mǎn)屏 ANSI 控制符第一次把 brew 的 stdout 接到前端時(shí)日志面板全是亂碼[32m Downloading https://... [0m[34m Pouring ...這些[32m、[0m不是文本內(nèi)容而是終端顏色控制符。brew 檢測(cè)到自己是輸出到 TTY 時(shí)會(huì)加上顏色當(dāng) Rust 用管道捕獲輸出時(shí)Homebrew 仍然按照帶顏色的方式輸出于是這些轉(zhuǎn)義序列就混進(jìn)了數(shù)據(jù)流。我有兩個(gè)層面的解決方案調(diào)用 brew 時(shí)盡量設(shè)置HOMEBREW_NO_COLOR1從源頭減少顏色輸出。在 Rust 端用strip_ansi_escapescrate 對(duì)所有行做一次清理雙保險(xiǎn)。從實(shí)際效果看第二層是真正兜底的因?yàn)椴皇撬休敵龆甲袷丨h(huán)境變量約定總會(huì)有一些子命令強(qiáng)制帶顏色。4.3 第三個(gè)坑Cask 安裝需要管理員權(quán)限brew 安裝普通 formula 基本不需要管理員權(quán)限但 Cask 不一樣。部分 Cask 安裝到 /Applications或者包本身是 pkg 格式執(zhí)行安裝腳本時(shí)需要寫(xiě)系統(tǒng)目錄普通用戶(hù)會(huì)遇到 Permission denied。一開(kāi)始我想得很簡(jiǎn)單讓整個(gè) BrewUI 應(yīng)用以 root 權(quán)限跑問(wèn)題不就解決了這顯然不行讓一個(gè) GUI 應(yīng)用長(zhǎng)期持有 root 權(quán)限等于給系統(tǒng)埋雷Homebrew 官方也非常反對(duì)這種用法。后來(lái)我采用的方案是“按需提權(quán)”先以普通權(quán)限執(zhí)行 brew 命令當(dāng)檢測(cè)到權(quán)限相關(guān)錯(cuò)誤時(shí)再改用 macOS 的osascript彈系統(tǒng)授權(quán)框osascript -e do shell script brew install --cask google-chrome with administrator privilegesosascript會(huì)調(diào)用系統(tǒng)的提權(quán)組件用戶(hù)會(huì)看到一個(gè)標(biāo)準(zhǔn)的 macOS 密碼彈窗。重點(diǎn)是這個(gè)提權(quán)只限當(dāng)前命令執(zhí)行完就結(jié)束B(niǎo)rewUI 應(yīng)用本身依然以普通用戶(hù)權(quán)限運(yùn)行。代價(jià)是密碼彈窗不能隱藏而且命令輸出捕獲會(huì)稍微麻煩一點(diǎn)需要把腳本輸出重定向到臨時(shí)文件再讀回來(lái)。4.4 第四個(gè)坑窗口關(guān)了后臺(tái) brew 進(jìn)程還在跑還有一個(gè)比較隱蔽的問(wèn)題。Tauri 的 command 默認(rèn)是異步的用戶(hù)在界面上點(diǎn)“升級(jí)”Rust 里 spawn 一個(gè) brew 進(jìn)程然后前端拿到返回值。但如果用戶(hù)這時(shí)候關(guān)掉主窗口Tauri 進(jìn)程還沒(méi)完全退出Rust 端的 Future 被 drop子進(jìn)程卻不一定跟著死。結(jié)果就是用戶(hù)以為 BrewUI 已經(jīng)關(guān)了但后臺(tái) brew 還在下載、還在編譯下次打開(kāi)應(yīng)用再點(diǎn)升級(jí)就撞上 Homebrew 的進(jìn)程鎖提示 “Another active Homebrew process is already in progress”。修復(fù)關(guān)鍵就是.kill_on_drop(true)它保證Command對(duì)象被 drop 時(shí)連帶的子進(jìn)程也會(huì)被終止。同時(shí)BrewUI 在應(yīng)用退出鉤子里顯式遍歷當(dāng)前運(yùn)行隊(duì)列把殘留命令全部 kill 掉。再加上全局任務(wù)隊(duì)列這個(gè)問(wèn)題基本就絕跡了。這個(gè)坑也讓我意識(shí)到凡是長(zhǎng)期運(yùn)行的子進(jìn)程都要把“進(jìn)程生命周期”和“應(yīng)用生命周期”綁在一起考慮不能只盯著執(zhí)行完的那條主路徑。5. 實(shí)測(cè)體驗(yàn)從打開(kāi)應(yīng)用到完成一次全量升級(jí)5.1 啟動(dòng)速度與內(nèi)存占用我用一臺(tái) 2020 年的 Intel Mac 做了測(cè)試系統(tǒng)狀態(tài)是 260 個(gè) formula 加 cask。階段耗時(shí)首次啟動(dòng)無(wú)緩存全量 info 刷新約 7 秒第二次啟動(dòng)緩存命中約 1.5 秒檢查更新brew outdated --json約 2 秒內(nèi)存占用方面BrewUI 整個(gè)應(yīng)用運(yùn)行起來(lái)穩(wěn)定在 40MB 左右。對(duì)比我之前用 Electron 做的原型光主進(jìn)程就吃了 180MB渲染進(jìn)程再占用幾十 MB。Tauri 這里節(jié)省得非常明顯對(duì)一個(gè)“開(kāi)發(fā)者工具”來(lái)說(shuō)這個(gè)內(nèi)存占用水平是可接受的。5.2 一次典型的升級(jí)操作一個(gè)相對(duì)完整的驗(yàn)證流程是這樣的打開(kāi) BrewUI主界面先顯示包列表左上角有“檢查更新”。我點(diǎn)擊之后頁(yè)面頂部出現(xiàn)一個(gè)進(jìn)度條大約兩秒后結(jié)果列出來(lái)了8 個(gè) formula 有更新2 個(gè) cask 有更新每個(gè)包后面都標(biāo)注了當(dāng)前版本和可用版本還可以展開(kāi)看依賴(lài)是否會(huì)聯(lián)動(dòng)升級(jí)。我沒(méi)有全選而是勾了 5 個(gè)自己常用的包點(diǎn)“升級(jí)所選”。右側(cè)抽屜式的日志面板開(kāi)始實(shí)時(shí)滾動(dòng)顯示 Upgrading 5 outdated packages: python3.12 3.12.1 - 3.12.2 ... Downloading https://...下載進(jìn)度、解壓狀態(tài)、鏈接狀態(tài)都一行行打出來(lái)整個(gè)升級(jí)過(guò)程大概花了 2 分鐘。其中有一步某個(gè)依賴(lài)下載失敗界面用紅色標(biāo)出了那一行日志升級(jí)任務(wù)整體標(biāo)記為失敗但已成功的包不受影響。這一點(diǎn)很實(shí)用至少用戶(hù)能精確看到是哪一步出了問(wèn)題。升級(jí)完我去“緩存與磁盤(pán)”面板。它先掃描目錄展示了 Cellar、Caskroom、下載緩存的占用情況。點(diǎn)“清理預(yù)覽”顯示可釋放空間約 1.2GB主要是下載緩存和舊版本殘留。確認(rèn)后執(zhí)行清理40 秒后磁盤(pán)空間釋放了日志里能看到每個(gè)被清理的路徑。5.3 高級(jí)用戶(hù)到底需不需要 GUI我在做 BrewUI 之前覺(jué)得自己不會(huì)用它——畢竟命令行太熟了。但實(shí)際用了幾周之后我發(fā)現(xiàn)它的價(jià)值不在于“比命令行快”而在于“讓決策更容易”。比如我想知道某個(gè)開(kāi)發(fā)機(jī)上到底哪個(gè)包占用磁盤(pán)最大以前得du -sh $(brew --prefix)/Cellar/*然后自己排序現(xiàn)在打開(kāi) BrewUI 按體積排序一眼就知道。我想看某個(gè)新引入的庫(kù)會(huì)影響哪些既有包依賴(lài)圖也比brew deps --tree的輸出直觀很多。再比如給剛?cè)肼毜耐峦扑]環(huán)境初始化工具以前得發(fā)一長(zhǎng)串命令還得解釋什么是環(huán)境變量?，F(xiàn)在直接把 BrewUI 發(fā)過(guò)去讓他自己在界面里搜索、安裝操作失誤的概率低很多。從團(tuán)隊(duì)的視角看這本質(zhì)上是用交互降低集體經(jīng)驗(yàn)成本。最后分享一點(diǎn)我的個(gè)人體會(huì)BrewUI 做了幾輪迭代之后我自己最大的收獲反而不是技術(shù)層面而是對(duì)“工具設(shè)計(jì)邊界”的理解。Homebrew 非常強(qiáng)大但它默認(rèn)的交互對(duì)象是命令行用戶(hù)屏幕后面是一堆文本。我要做的不是改變 Homebrew而是把“文本背后的狀態(tài)”變成人更容易理解的圖形。這一點(diǎn)想清楚之后很多設(shè)計(jì)決策都順了。如果你想在 BrewUI 基礎(chǔ)上做二次開(kāi)發(fā)或者自己也做一個(gè)針對(duì)其他包管理器的 GUI我有幾個(gè)建議永遠(yuǎn)優(yōu)先考慮“操作預(yù)覽”尤其是卸載和清理這類(lèi)不可逆操作。所有命令執(zhí)行都要考慮取消和超時(shí)不要假設(shè)用戶(hù)會(huì)老老實(shí)實(shí)等完。日志是 GUI 最容易被忽視但同時(shí)最重要的部分一坨“假裝有反饋”的進(jìn)度條頂不過(guò)幾行真實(shí)日志。我目前還在持續(xù)完善 BrewUI后續(xù)計(jì)劃把 Homebrew bundle 的導(dǎo)入導(dǎo)出做成界面化操作讓換新電腦時(shí)恢復(fù)開(kāi)發(fā)環(huán)境的成本再低一點(diǎn)。工具這種東西做出來(lái)的那一刻永遠(yuǎn)不完美但只要讓一個(gè)原本不敢碰終端的人成功維護(hù)好了自己的開(kāi)發(fā)環(huán)境它就值回票了。