拓冰网站定制 
我自己的电脑上常年跑着三百多个 Homebrew 包从 Node 到 ffmpeg 到各种奇奇怪怪的小工具全靠命令行brew install一把梭。但每次同事想借我电脑装个东西看到终端就一脸懵或者我自己隔三差五想看看哪些包该升级了也只能敲brew outdated加一堆参数慢慢翻。所以我做了 BrewUI一个把 Homebrew 包管理搬到桌面窗体的可视化工具让“装软件、卸软件、查依赖、看更新”这件事不再依赖记忆和命令行的肌肉记忆。这篇文章我会完整拆解 BrewUI 的设计思路、技术选型、核心实现以及我在实际开发中踩过的坑希望能给想做同类工具或者对桌面端技术栈感兴趣的朋友一些参考。BrewUI 本质上是一层带图形界面的封装底层还是老老实实调 Homebrew 的命令行工具。我知道有人会说“那不就是套个壳嘛”但套壳和套壳之间差距很大如果只是把终端输出显示到网页上那确实没多大价值但如果你能做到“打开界面就看到所有已安装的软件、状态一目了然、点击按钮就完成操作、依赖关系画成可浏览的结构”体验和效率是完全不同的。这篇文章面向的读者是那些对 Homebrew 本身有一定了解、想提升 Mac 软件管理效率同时也对 Electron/Tauri 这类桌面端技术、对“怎么安全地调用系统命令”这件事感兴趣的人。1. BrewUI 是什么我为什么要做这个桌面端工具1.1 终端包管理的门槛我见过太多人卡在“想装软件但记不住命令”这一步。Homebrew 的设计逻辑其实很统一brew install 包名、brew uninstall 包名、brew upgrade 包名但对不长用命令行的人来说每一次打开终端都需要面对一个冷冰冰的提示符还要分清 formula命令行工具和 cask图形化应用的区别更别提brew services、brew bundle这些进阶用法了。我自己用 Homebrew 用了快十年虽然命令早就刻进肌肉记忆了但有个场景一直很让我头疼我想批量升级一堆包又想知道它们之间谁依赖谁命令行里虽然有brew deps --tree这类命令但输出是一大段树状文本眼睛看花了也理不清结构。还有brew list的展示方式一条命令刷几十行包名没有版本号、没有安装时间、没有大小信息真的很难快速定位。所以 BrewUI 的出发点很直接保留 Homebrew 的强大能力把“信息的阅读”和“操作的触达”都改成图形界面。对新手来说所有操作变成按钮和表单对老手来说复杂信息变成结构化的列表和关系图省得在终端里反复敲命令对比。1.2 BrewUI 的定位与核心功能拆解BrewUI 不是要替代 Homebrew 命令而是在 Homebrew 之上提供一层“指挥中心”。我的核心功能设计围绕四个维度展开可视化的软件清单已安装的 formula、cask 分开展示每一条包含版本、最新版本、大小、安装时间、是否过期等字段支持排序和过滤。一键式的操作入口安装、升级、卸载都封装成按钮批量勾选后可以批量操作操作过程中提供实时日志输出。依赖关系浏览查看任意包的 dependencies它依赖谁和 dependents谁依赖它用可展开的树形结构呈现替代brew deps --tree的文本输出。更新提醒与系统信息启动时自动检测可升级的包、过期的 tap、可清理的缓存和旧版本像系统设置里的软件更新面板一样识别。一句话总结它把 brew 命令族的“低频但必需”的操作做成了一个桌面 App 里随时可点、可看、可感知的体验。这恰好也是我做这个项目时一直在打磨的方向——不是堆功能而是确保每个功能都有人真的会用。2. 技术选型解析为什么是 Electron React Node2.1 桌面壳的选择Electron 与 Tauri 的取舍桌面端方案我首先排除了原生开发。不是原生不行而是 BrewUI 本质上是一个“信息展示 命令调度”的应用界面迭代速度很重要而且我需要 Web 生态里非常成熟的数据可视化组件在 SwiftUI 或 Objective-C 里实现同样的东西成本高得多。剩下的选择基本就是 Electron 和 Tauri。我最初做过一版 Tauri 原型Rust 后端 WebView 前端二进制体积小、内存占用低看起来很香。但实际写下来最大的问题在于“系统命令的调用”。Tauri 里操作外部进程需要 Rust 侧用std::process::Command自己处理管道、超时、信号、权限虽然也能做但每增加一个交互场景就要改一次 Rust 代码开发效率确实不如 Node 侧直接child_process一把梭来得快。另外 Electron 的生态里像electron-builder、electron-updater、electron-store这些配套太成熟了打包、自动更新、配置持久化几乎开箱即用。Electron 的缺点我也认包体大、内存吃得多。但对 BrewUI 这个应用场景来说用户的电脑几乎都是开发机16GB 内存起步Electron 占的那几百兆真不算什么。稳定、快速、可维护才是我更看重的。2.2 前端渲染层与数据流设计前端我选了 React TypeScript。选 React 没有特别倾向性主要是团队里熟悉这套而且后文要提到的依赖关系树组件React 生态里有更成熟的方案。数据的组织和状态管理我采用了一个很“老派”但也很好维护的方案主进程负责所有和 brew 相关的逻辑通过 IPC 向渲染进程暴露统一的 API渲染进程内部用一组 React Hooks 管理数据。// src/types/brew.ts export interface BrewFormula { name: string; version: string; latestVersion?: string; installed_on_request?: boolean; dependencies?: string[]; installed_kegs?: string[]; outdated?: boolean; caveats?: string; size?: number; } export interface BrewCask { name: string[]; version: string; latestVersion?: string; installed?: boolean; outdated?: boolean; tokens?: string[]; artifact?: string[]; }界面数据的获取全部通过主进程转发渲染进程不直接碰child_process。这么做的好处有两个一是权限隔离即使渲染层被注入恶意脚本能操作的范围也限制在主进程提供的 API 里二是状态统一所有 brew 命令的执行状态、日志流、异常信息都走同一套 IPC 事件机制界面层无需关心底层是“正在解析输出”还是“正在等待 sudo 密码”。2.3 系统桥接层命令执行与权限处理BrewUI 最关键的部分在系统桥接层也就是主进程里所有以spawn为中心的逻辑。为什么用spawn而不是exec原因有三点第一brew 命令的输出可能非常长比如brew update或brew install在编译时会产生大量中间信息exec默认会用maxBuffer限制输出很容易爆掉第二spawn能拿到实时的 stdout/stderr 流我可以把进度逐行推送到界面用户体验更像是看到一个终端面板在滚动而不是等全部跑完才看到一坨文本第三spawn可以更精细地控制信号比如安装过程中用户想取消操作我能在进程级别安全地发送 SIGTERM而不是 kill 整个进程树导致留下半残状态。// src/main/brew.ts简化 import { spawn } from child_process; import { EventEmitter } from events; import { quote } from shell-quote; export class BrewRunner extends EventEmitter { private queue: Array{ cmd: string; args: string[] } []; private running false; run(cmd: string, args: string[] []) { return new Promisevoid((resolve, reject) { this.queue.push({ cmd, args }); this.emit(enqueue, { cmd, args }); if (!this.running) { this.executeNext(resolve, reject); } }); } private executeNext(resolve, reject) { const item this.queue.shift(); if (!item) { this.running false; return; } this.running true; const child spawn(brew, [item.cmd, ...item.args], { env: { ...process.env, PATH: this.getPath(), HOMEBREW_NO_AUTO_UPDATE: 1 }, stdio: [pipe, pipe, pipe], }); child.stdout.on(data, (data) this.emit(log, data.toString())); child.stderr.on(data, (data) this.emit(log, data.toString())); child.on(close, (code) { this.emit(done, { code }); if (code 0) { this.executeNext(resolve, reject); } else { reject(new Error(brew ${item.cmd} exit ${code})); } }); } }另一个绕不开的事情是权限。有些 cask 安装到/Applications或写入系统目录时Homebrew 会提示输入 sudo 密码。在终端里输入密码也就一瞬间的事但在 GUI 里spawn出来的子进程没有和终端关联的 ttysudo 无法直接读取密码命令会卡住。我最终的做法是在运行这类命令前先通过系统弹窗式osascript以图形化方式获取管理员密码然后通过sudo -S从 stdin 传入同时尽量限制密码只在内存中生效、用完立刻销毁。注意所有涉及 sudo 的命令我都会用--password-stdin或-S来避免密码出现在进程参数列表里。进程参数是全局可见的任何用户都能通过ps aux看到绝不能把密码直接作为参数传进去。这是处理敏感信息的基本底线。3. 核心功能实现与界面设计3.1 软件列表的获取与状态判断软件列表是 BrewUI 的门面我花了很大的精力在“数据的真实性和及时性”上。最初我尝试用brew list解析文本来获取已安装包再逐条调用brew info补版本信息结果包一多整个列表要等十几秒体验非常差。后来我转向 Homebrew 官方提供的 JSON API通过一条命令就能拿到完整的安装状态和依赖信息# 获取所有已安装 formula 的完整 JSON brew info --jsonv2 --installed # 获取所有已安装 cask 的完整 JSON brew list --cask --jsonv2把--jsonv2的输出缓存到本地只在实际执行安装/卸载/升级操作后刷新对应条目这样列表面板的响应速度可以快到秒开。针对“是否有新版本”这个状态可以用brew outdated --jsonv2一次性拿到过期的包列表再和本地缓存合并标记。这里有个容易踩的坑也是我想给所有做“包管理类工具”的朋友的一个经验不要每次都直接调brew update来刷新版本号。brew update会拉取远端仓库慢不说频繁执行还会触发 GitHub API 的限流。BrewUI 的做法是用户手动点刷新或者通过菜单触发才执行日常启动只做本地缓存和brew outdated把网络请求控制在最小范围。3.2 安装/卸载/升级操作的并发控制Homebrew 自己带了一把全局锁$(brew --prefix)/var/homebrew/locks同一时间只能跑一个写类型的操作比如同时跑两个brew install必定有一个会等着拿锁。所以我在 BrewRunner 里实现了一个简单的任务队列所有需要执行的命令按顺序排队界面同时只能有一个进行中的任务。队列机制看起来简单但实际使用中帮了大忙。最典型的场景是用户勾选了一堆包点“批量升级”如果我用 Promise.all 并发跑跑一半就可能被锁卡住用队列串行执行每个包升级完毕立刻反馈到列表上用户能清晰看到哪个包成功、哪个包失败失败的原因也能单独显示。我还要注意取消操作的细节。brew 在写文件过程中被强杀很容易留下破损的符号链接或者未完成的 keg。所以在用户点击“取消”时BrewRunner 不会直接 kill 子进程而是先发送 SIGINT让 Homebrew 自己的信号处理逻辑去清理临时文件如果几秒后还没有退出再升级成 SIGTERM。这个处理比简单粗暴 kill 要稳妥得多。3.3 依赖关系与 tap 的可视化展示依赖关系是我自己最想要的功能。brew deps --tree wget能输出一段缩进文本但包一多很难看清。BrewUI 的依赖面板采用了“自顶向下可展开树”的布局以当前选中包为根节点第一层显示“直接依赖”展开之后看到“依赖的依赖”每条边上标注版本约束条件另一侧有“反向依赖”列表显示哪些包正依赖着它。我在 JSON API 的基础上做了一层缓存计算把每次brew info --jsonv2返回的所有 dependencies 关系构造成一张有向图存成邻接表结构这样查询任意包的上下游都只需要 O(1) 的读表操作。用户在整个 App 里浏览的时间越长关系数据越完整点击任意包都能瞬间展示完整依赖链。Tap 的可视化我也做了。Homebrew 的 tap 就是镜像和软件源的扩展集合里面可能会有 core 之外的第三方仓库。BrewUI 里可以查看当前已经添加了哪些 tap、每个 tap 下有多少个包、最近一次更新的时间用来理解当前机器上软件来源的分布情况。对于排查“为什么某个包装不上”的场景tap 的信息甚至比依赖关系更关键。3.4 搜索过滤、批量操作与“非侵入”设计搜索功能很像软件包管理器应有的样子输入关键词实时匹配 formula 和 cask结果区分“已安装”和“未安装”未安装的可以直接点安装。搜索走的是远端 API查询速度取决于网络所以我加了 300ms 的防抖同时也支持先查本地缓存再异步去远端补充信息。批量操作是最需要克制的地方。技术上我可以让用户勾选 50 个包一次性点升级但我不会这么设计。队列的串行执行已经保证了稳定如果用户在界面上看到 50 个任务同时挂着意义不明反而可以在每个任务完成后局部刷新对应包的状态其余不受影响。这个“带反馈的批量操作”体验比那种统一的 loading 转圈要舒服得多。“非侵入”是我在做 UI 设计时给自己的一个准则BrewUI 不应该让用户觉得自己在操作一个复杂的命令行工具而是像在用系统自带的软件管理界面。按钮文案要清楚比如“升级”“移除”“重新安装”操作前要有确认弹窗危险操作比如卸载会连带影响其他包的包要先用醒目的颜色提示。真正做到“不懂 brew 的人也能安全使用”。4. 实操过程记录从初始化到打包分发4.1 环境准备与项目初始化开发 BrewUI 的机器是一台 macOS 13 的 Apple Silicon MacBookXcode 命令行工具齐全Homebrew 已经装好Node 用的是 20 LTS。项目初始化直接用了npm create electron-vite的 React TypeScript 模板这个模板内置了主进程、预加载脚本、渲染进程的三层结构省去了自己手动配置 Webpack/Vite 和 Electron 的繁琐步骤。npm create electron-vitelatest brewui -- --template react-ts cd brewui npm install electron-builder --save-dev npm install shell-quote electron-store选 electron-vite 模板还有一个原因它默认就能很好地处理开发环境和打包环境的差异。开发时渲染进程跑在 Vite 的 Dev Server 上主进程改动会触发 Electron 自动重启打包时用 electron-builder 统一产出 dmg 和 zip不用额外写复杂的脚本。4.2 目录结构与模块划分项目目录结构决定了我后续能走多快所以我刻意把“和 brew 相关的逻辑”和“Electron 壳子相关的逻辑”分开brewui/ ├── src/ │ ├── main/ │ │ ├── index.ts # 主进程入口创建窗口、注册 IPC │ │ ├── brew.ts # BrewRunner、命令队列、日志事件 │ │ ├── brewApi.ts # 对 brew 命令的高层封装install/uninstall/upgrade │ │ ├── sudo.ts # sudo 密码的安全获取和传递 │ │ └── store.ts # electron-store 封装存配置和缓存 │ ├── preload/ │ │ └── index.ts # contextBridge 暴露安全的 API │ ├── renderer/ │ │ ├── src/ │ │ │ ├── components/ # FormulaList、CaskList、DependencyTree 等 │ │ │ ├── hooks/ # useBrewList、useOutdated 等 │ │ │ ├── store/ # zustand 全局状态 │ │ │ └── App.tsx │ │ └── index.html ├── resources/ │ └── icon.png └── electron-builder.ymlpreload 脚本是渲染进程和主进程之间的唯一通道。我通过contextBridge暴露一组白名单 API例如window.brew.listInstalled()、window.brew.install(name)等渲染进程拿不到 Node 的任何能力只能调用这些方法。这不仅是安全最佳实践也能让代码边界清楚界面层永远不会出现require(child_process)这种坏味道。4.3 核心代码实现列表数据获取。我封装了一个getInstalledFormulas方法读取 JSON 后转换成内部类型// src/main/brewApi.ts import { execFile } from child_process; import { promisify } from util; const execFileAsync promisify(execFile); const BREW /opt/homebrew/bin/brew; // Apple Silicon 默认路径 export async function getInstalledFormulas() { const { stdout } await execFileAsync(BREW, [info, --jsonv2, --installed], { maxBuffer: 1024 * 1024 * 20, env: { ...process.env, PATH: /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin }, }); const json JSON.parse(stdout); return json.formulae as BrewFormula[]; }Apple Silicon 的 Homebrew 前缀默认是/opt/homebrewIntel Mac 则是/usr/local我封装了一个getBrewPath()来做自动探测检查这两个常见路径哪个存在同时也支持用户从设置里手动指定。安装与升级。通过 IPC 交互时渲染进程调用window.brew.install(wget)主进程把任务塞进 BrewRunner任务开始后通过mainWindow.webContents.send(brew:log, line)实时推日志// preload/index.ts contextBridge.exposeInMainWorld(brew, { install: (name: string) ipcRenderer.invoke(brew:install, name), uninstall: (name: string) ipcRenderer.invoke(brew:uninstall, name), upgrade: (name: string) ipcRenderer.invoke(brew:upgrade, name), onLog: (callback: (line: string) void) { const listener (_e: IpcRendererEvent, line: string) callback(line); ipcRenderer.on(brew:log, listener); return () ipcRenderer.removeListener(brew:log, listener); }, });依赖图构建。在brewApi.ts里维护一个dependencyGraph对象// src/main/dependencyGraph.ts interface Graph { nodes: Setstring; edges: Mapstring, string[]; // parent - children } export function buildGraph(formulas: BrewFormula[]) { const graph: Graph { nodes: new Set(), edges: new Map() }; for (const f of formulas) { graph.nodes.add(f.name); for (const dep of f.dependencies ?? []) { if (!graph.edges.has(f.name)) graph.edges.set(f.name, []); graph.edges.get(f.name)!.push(dep); graph.nodes.add(dep); } } return graph; } export function getDependents(graph: Graph, name: string) { const result: string[] []; for (const [parent, children] of graph.edges.entries()) { if (children.includes(name)) result.push(parent); } return result; }4.4 打包分发与 electron-builder 配置打包配置我放在electron-builder.yml里关键点是如何正确带上资源文件和图标。BrewUI 本身不打包任何 brew 二进制它是在用户已装 Homebrew 的机器上运行的因此安装包可以做得相对小主要就是 Electron 运行时加应用代码。appId: com.brewui.app productName: BrewUI directories: output: release files: - out/**/* - resources/**/* mac: category: public.app-category.developer-tools target: - dmg - zip icon: resources/icon.png dmg: contents: - x: 130 y: 220 - x: 410 y: 220 type: link path: /Applications打包命令很简单npm run build npm run dist。产物会在release目录下生成一个 dmg用户挂载后把 BrewUI 拖到 Applications 里就行。注意macOS 对未签名或未公证的应用有 Gatekeeper 限制首次打开需要在“系统设置 - 隐私与安全性”里手动允许。如果你要分发到更广的范围建议注册 Apple Developer 账号做签名和 notarization这一步不能省否则用户会卡在“已损坏”的提示上。4.5 快速体验方式如果你只想先体验一下 BrewUI 的感觉其实不用打包直接跑开发模式就行npm install npm run dev这个命令会启动 Electron 窗口加载 Vite Dev Server。第一次打开它会扫描已安装的 formula 和 cask界面上的“已安装”“可升级”列表很快就能渲染出来。此时可以试着搜索几个没装的包、点一下安装按钮观察底部的日志面板如何实时显示 brew 的输出这个体验和最终打包后的版本完全一致。5. 常见问题与排查技巧实录5.1 GUI 应用里 brew 命令找不到这是最经典的问题我一开始也没意识到。macOS 上通过 LaunchServices 启动 GUI App 时继承的环境变量和终端里完全不一样PATH通常只有/usr/bin:/bin:/usr/sbin:/sbin而 Homebrew 的路径在/opt/homebrew/bin或/usr/local/bin所以spawn(brew, ...)会直接报spawn brew ENOENT。解决方案是不要在代码里依赖系统 PATH而是显式探测并拼接。我写了一个getBrewPath()方法返回一个绝对路径比如/opt/homebrew/bin/brew同时把/opt/homebrew/bin:/usr/local/bin塞进子进程的 env.PATH。这个坑给了我很深的教训GUI 应用的运行环境不等于 shell 环境凡是依赖外部命令的应用都要显式指定路径不能假设环境变量一定存在。5.2 sudo 密码无法传入 brew 子进程前面提到过cask 安装到系统级目录时需要管理员权限。终端里跑brew install --cask xxx时sudo 能通过/dev/tty读取用户输入的密码但在 GUI 应用里spawn 出来的子进程没有 ttysudo 读不到任何输入命令会卡在密码提示界面日志看起来像是“死掉了”。我的解决办法是先通过一个模态窗口让用户输入管理员密码然后用spawn(sudo, [-S, --, ...])的方式把密码写进 stdin执行完成后立刻清空对应内存。实际使用中还有一个安全细节sudo -S 读取 stdin 的第一行作为密码剩下的行才会传给目标命令。这个顺序必须小心处理不然密码会被当成命令参数传给 brew造成严重的安全事故。因此我在实现时单独用小脚本测试了各种输入组合确保密码不会混入后续命令。如果实在不想处理 sudo 流程也可以要求用户提前在终端里执行一次brew install --cask --verbose xxx或者用 osascript 弹系统对话框输入密码但这样体验会打折。好在brew自带的“特权命令”大多可以用sudo -n加上缓存凭据的方式来规避重复输入在用户已经通过图形化授权过一次的情况下短暂时间内再次使用 sudo 不会重复弹窗。5.3 Intel 与 Apple Silicon 路径差异Homebrew 在两种芯片架构下的安装路径完全不同Intel Mac 通常是/usr/localApple Silicon 是/opt/homebrew。这看起来只是一个小路径判断但影响面很大不仅 brew 二进制的位置不同Cellar、Caskroom、tap 的路径也全不同。如果程序只在/opt/homebrew找 brew旧 Intel 机器上就会直接报不存在。我的建议是做双路径探测同时提供设置页让高级用户手动指定。还要注意一种更隐蔽的情况Rosetta 模式下运行的 Intel 版 Homebrew路径是/usr/local但它和原生 ARM 环境共享同一个 GUI 进程时可能会出现“同一个机器有两个 brew”的状态。BrewUI 会把这些信息显示在“系统信息”面板方便用户识别当前上下文。5.4 Homebrew JSON API 变更导致列表空白Homebrew 的--jsonv2输出格式相对稳定但不代表永远不变。比如有一段时间brew list --cask --jsonv2的字段结构和brew info --jsonv2并不完全一致如果你用一套解析逻辑去处理两处数据字段名对不上列表就会空白或者报错。我的方法是给每个 JSON 解析函数写独立的类型断言和空值兜底宁可某个字段显示为“未知”也不能因为一个字段缺失而让整页崩溃。同时我在启动时把 JSON 的 schema 版本号记下来一旦发现 brew 输出里新增了标记字段就触发一次“数据结构校验”用本地日志提醒开发者查看是否有格式变更。做这种工具的心里要时刻有数上游命令行工具的格式不保证长期兼容代码里必须预留容错空间。5.5 常见问题速查表现象可能原因解决方案列表为空控制台报 ENOENT未找到 brew 可执行文件检查 getBrewPath 是否正确尝试手动指定路径操作卡在 “需要管理员密码”spawn 子进程没有 tty使用 sudo -S 配合图形化密码输入或提示用户预授权升级很慢甚至一直转圈每次都触发 brew update改用 brew outdated只在手动刷新时执行 update格式化大量包时界面卡死渲染进程一次性处理过多 DOM使用虚拟滚动列表限制一次性渲染节点数部分软件显示已安装但打不开cask 安装的是 .pkg 或需要额外配置在详情面板展示 caveats 和 artifact 信息Jenkins/CI 环境无法使用CI 里没有图形会话增加 headless 模式只提供 CLI 调用和 JSON 输出还有一些细节我想单独提醒日志面板不要无限增长超过一定行数就截断操作按钮在任务进行中要统一 disable避免用户同时点多个操作造成队列混乱卸载有依赖关联的包之前一定要先展示“下列包也依赖了它”的警告不然用户很容易无意识拆掉半套环境。这些都是我在真实使用中一点点补上的血泪经验。做这个项目最深的体会是工具类应用的护城河不在 UI 多炫酷而在“使用它的过程中用户会不会觉得安全、可控、不焦虑”。BrewUI 从第一版只能看列表到后来能装能卸、能看依赖、能处理权限每一步都来自真实需求。最后再分享一个小技巧如果你也想做类似的包管理 GUI建议一开始就把所有 brew 相关命令收敛到一个模块里不要散落在各个业务逻辑中这样即使 Homebrew 的命令格式变了你也只需要改这一个文件而不是翻遍整个代码库。BrewUI 后续还可以扩展的方向包括 brew services 的管理界面、自动清理缓存的功能、以及一键生成维护仓库用的 Brewfile这些都是顺手就能加进去的新大陆。 BrewUI：把 Homebrew 变成可视化桌面应用，轻松管理包依赖与升级
我自己的电脑上常年跑着三百多个 Homebrew 包从 Node 到 ffmpeg 到各种奇奇怪怪的小工具全靠命令行brew install一把梭。但每次同事想借我电脑装个东西看到终端就一脸懵或者我自己隔三差五想看看哪些包该升级了也只能敲brew outdated加一堆参数慢慢翻。所以我做了 BrewUI一个把 Homebrew 包管理搬到桌面窗体的可视化工具让“装软件、卸软件、查依赖、看更新”这件事不再依赖记忆和命令行的肌肉记忆。这篇文章我会完整拆解 BrewUI 的设计思路、技术选型、核心实现以及我在实际开发中踩过的坑希望能给想做同类工具或者对桌面端技术栈感兴趣的朋友一些参考。BrewUI 本质上是一层带图形界面的封装底层还是老老实实调 Homebrew 的命令行工具。我知道有人会说“那不就是套个壳嘛”但套壳和套壳之间差距很大如果只是把终端输出显示到网页上那确实没多大价值但如果你能做到“打开界面就看到所有已安装的软件、状态一目了然、点击按钮就完成操作、依赖关系画成可浏览的结构”体验和效率是完全不同的。这篇文章面向的读者是那些对 Homebrew 本身有一定了解、想提升 Mac 软件管理效率同时也对 Electron/Tauri 这类桌面端技术、对“怎么安全地调用系统命令”这件事感兴趣的人。1. BrewUI 是什么我为什么要做这个桌面端工具1.1 终端包管理的门槛我见过太多人卡在“想装软件但记不住命令”这一步。Homebrew 的设计逻辑其实很统一brew install 包名、brew uninstall 包名、brew upgrade 包名但对不长用命令行的人来说每一次打开终端都需要面对一个冷冰冰的提示符还要分清 formula命令行工具和 cask图形化应用的区别更别提brew services、brew bundle这些进阶用法了。我自己用 Homebrew 用了快十年虽然命令早就刻进肌肉记忆了但有个场景一直很让我头疼我想批量升级一堆包又想知道它们之间谁依赖谁命令行里虽然有brew deps --tree这类命令但输出是一大段树状文本眼睛看花了也理不清结构。还有brew list的展示方式一条命令刷几十行包名没有版本号、没有安装时间、没有大小信息真的很难快速定位。所以 BrewUI 的出发点很直接保留 Homebrew 的强大能力把“信息的阅读”和“操作的触达”都改成图形界面。对新手来说所有操作变成按钮和表单对老手来说复杂信息变成结构化的列表和关系图省得在终端里反复敲命令对比。1.2 BrewUI 的定位与核心功能拆解BrewUI 不是要替代 Homebrew 命令而是在 Homebrew 之上提供一层“指挥中心”。我的核心功能设计围绕四个维度展开可视化的软件清单已安装的 formula、cask 分开展示每一条包含版本、最新版本、大小、安装时间、是否过期等字段支持排序和过滤。一键式的操作入口安装、升级、卸载都封装成按钮批量勾选后可以批量操作操作过程中提供实时日志输出。依赖关系浏览查看任意包的 dependencies它依赖谁和 dependents谁依赖它用可展开的树形结构呈现替代brew deps --tree的文本输出。更新提醒与系统信息启动时自动检测可升级的包、过期的 tap、可清理的缓存和旧版本像系统设置里的软件更新面板一样识别。一句话总结它把 brew 命令族的“低频但必需”的操作做成了一个桌面 App 里随时可点、可看、可感知的体验。这恰好也是我做这个项目时一直在打磨的方向——不是堆功能而是确保每个功能都有人真的会用。2. 技术选型解析为什么是 Electron React Node2.1 桌面壳的选择Electron 与 Tauri 的取舍桌面端方案我首先排除了原生开发。不是原生不行而是 BrewUI 本质上是一个“信息展示 命令调度”的应用界面迭代速度很重要而且我需要 Web 生态里非常成熟的数据可视化组件在 SwiftUI 或 Objective-C 里实现同样的东西成本高得多。剩下的选择基本就是 Electron 和 Tauri。我最初做过一版 Tauri 原型Rust 后端 WebView 前端二进制体积小、内存占用低看起来很香。但实际写下来最大的问题在于“系统命令的调用”。Tauri 里操作外部进程需要 Rust 侧用std::process::Command自己处理管道、超时、信号、权限虽然也能做但每增加一个交互场景就要改一次 Rust 代码开发效率确实不如 Node 侧直接child_process一把梭来得快。另外 Electron 的生态里像electron-builder、electron-updater、electron-store这些配套太成熟了打包、自动更新、配置持久化几乎开箱即用。Electron 的缺点我也认包体大、内存吃得多。但对 BrewUI 这个应用场景来说用户的电脑几乎都是开发机16GB 内存起步Electron 占的那几百兆真不算什么。稳定、快速、可维护才是我更看重的。2.2 前端渲染层与数据流设计前端我选了 React TypeScript。选 React 没有特别倾向性主要是团队里熟悉这套而且后文要提到的依赖关系树组件React 生态里有更成熟的方案。数据的组织和状态管理我采用了一个很“老派”但也很好维护的方案主进程负责所有和 brew 相关的逻辑通过 IPC 向渲染进程暴露统一的 API渲染进程内部用一组 React Hooks 管理数据。// src/types/brew.ts export interface BrewFormula { name: string; version: string; latestVersion?: string; installed_on_request?: boolean; dependencies?: string[]; installed_kegs?: string[]; outdated?: boolean; caveats?: string; size?: number; } export interface BrewCask { name: string[]; version: string; latestVersion?: string; installed?: boolean; outdated?: boolean; tokens?: string[]; artifact?: string[]; }界面数据的获取全部通过主进程转发渲染进程不直接碰child_process。这么做的好处有两个一是权限隔离即使渲染层被注入恶意脚本能操作的范围也限制在主进程提供的 API 里二是状态统一所有 brew 命令的执行状态、日志流、异常信息都走同一套 IPC 事件机制界面层无需关心底层是“正在解析输出”还是“正在等待 sudo 密码”。2.3 系统桥接层命令执行与权限处理BrewUI 最关键的部分在系统桥接层也就是主进程里所有以spawn为中心的逻辑。为什么用spawn而不是exec原因有三点第一brew 命令的输出可能非常长比如brew update或brew install在编译时会产生大量中间信息exec默认会用maxBuffer限制输出很容易爆掉第二spawn能拿到实时的 stdout/stderr 流我可以把进度逐行推送到界面用户体验更像是看到一个终端面板在滚动而不是等全部跑完才看到一坨文本第三spawn可以更精细地控制信号比如安装过程中用户想取消操作我能在进程级别安全地发送 SIGTERM而不是 kill 整个进程树导致留下半残状态。// src/main/brew.ts简化 import { spawn } from child_process; import { EventEmitter } from events; import { quote } from shell-quote; export class BrewRunner extends EventEmitter { private queue: Array{ cmd: string; args: string[] } []; private running false; run(cmd: string, args: string[] []) { return new Promisevoid((resolve, reject) { this.queue.push({ cmd, args }); this.emit(enqueue, { cmd, args }); if (!this.running) { this.executeNext(resolve, reject); } }); } private executeNext(resolve, reject) { const item this.queue.shift(); if (!item) { this.running false; return; } this.running true; const child spawn(brew, [item.cmd, ...item.args], { env: { ...process.env, PATH: this.getPath(), HOMEBREW_NO_AUTO_UPDATE: 1 }, stdio: [pipe, pipe, pipe], }); child.stdout.on(data, (data) this.emit(log, data.toString())); child.stderr.on(data, (data) this.emit(log, data.toString())); child.on(close, (code) { this.emit(done, { code }); if (code 0) { this.executeNext(resolve, reject); } else { reject(new Error(brew ${item.cmd} exit ${code})); } }); } }另一个绕不开的事情是权限。有些 cask 安装到/Applications或写入系统目录时Homebrew 会提示输入 sudo 密码。在终端里输入密码也就一瞬间的事但在 GUI 里spawn出来的子进程没有和终端关联的 ttysudo 无法直接读取密码命令会卡住。我最终的做法是在运行这类命令前先通过系统弹窗式osascript以图形化方式获取管理员密码然后通过sudo -S从 stdin 传入同时尽量限制密码只在内存中生效、用完立刻销毁。注意所有涉及 sudo 的命令我都会用--password-stdin或-S来避免密码出现在进程参数列表里。进程参数是全局可见的任何用户都能通过ps aux看到绝不能把密码直接作为参数传进去。这是处理敏感信息的基本底线。3. 核心功能实现与界面设计3.1 软件列表的获取与状态判断软件列表是 BrewUI 的门面我花了很大的精力在“数据的真实性和及时性”上。最初我尝试用brew list解析文本来获取已安装包再逐条调用brew info补版本信息结果包一多整个列表要等十几秒体验非常差。后来我转向 Homebrew 官方提供的 JSON API通过一条命令就能拿到完整的安装状态和依赖信息# 获取所有已安装 formula 的完整 JSON brew info --jsonv2 --installed # 获取所有已安装 cask 的完整 JSON brew list --cask --jsonv2把--jsonv2的输出缓存到本地只在实际执行安装/卸载/升级操作后刷新对应条目这样列表面板的响应速度可以快到秒开。针对“是否有新版本”这个状态可以用brew outdated --jsonv2一次性拿到过期的包列表再和本地缓存合并标记。这里有个容易踩的坑也是我想给所有做“包管理类工具”的朋友的一个经验不要每次都直接调brew update来刷新版本号。brew update会拉取远端仓库慢不说频繁执行还会触发 GitHub API 的限流。BrewUI 的做法是用户手动点刷新或者通过菜单触发才执行日常启动只做本地缓存和brew outdated把网络请求控制在最小范围。3.2 安装/卸载/升级操作的并发控制Homebrew 自己带了一把全局锁$(brew --prefix)/var/homebrew/locks同一时间只能跑一个写类型的操作比如同时跑两个brew install必定有一个会等着拿锁。所以我在 BrewRunner 里实现了一个简单的任务队列所有需要执行的命令按顺序排队界面同时只能有一个进行中的任务。队列机制看起来简单但实际使用中帮了大忙。最典型的场景是用户勾选了一堆包点“批量升级”如果我用 Promise.all 并发跑跑一半就可能被锁卡住用队列串行执行每个包升级完毕立刻反馈到列表上用户能清晰看到哪个包成功、哪个包失败失败的原因也能单独显示。我还要注意取消操作的细节。brew 在写文件过程中被强杀很容易留下破损的符号链接或者未完成的 keg。所以在用户点击“取消”时BrewRunner 不会直接 kill 子进程而是先发送 SIGINT让 Homebrew 自己的信号处理逻辑去清理临时文件如果几秒后还没有退出再升级成 SIGTERM。这个处理比简单粗暴 kill 要稳妥得多。3.3 依赖关系与 tap 的可视化展示依赖关系是我自己最想要的功能。brew deps --tree wget能输出一段缩进文本但包一多很难看清。BrewUI 的依赖面板采用了“自顶向下可展开树”的布局以当前选中包为根节点第一层显示“直接依赖”展开之后看到“依赖的依赖”每条边上标注版本约束条件另一侧有“反向依赖”列表显示哪些包正依赖着它。我在 JSON API 的基础上做了一层缓存计算把每次brew info --jsonv2返回的所有 dependencies 关系构造成一张有向图存成邻接表结构这样查询任意包的上下游都只需要 O(1) 的读表操作。用户在整个 App 里浏览的时间越长关系数据越完整点击任意包都能瞬间展示完整依赖链。Tap 的可视化我也做了。Homebrew 的 tap 就是镜像和软件源的扩展集合里面可能会有 core 之外的第三方仓库。BrewUI 里可以查看当前已经添加了哪些 tap、每个 tap 下有多少个包、最近一次更新的时间用来理解当前机器上软件来源的分布情况。对于排查“为什么某个包装不上”的场景tap 的信息甚至比依赖关系更关键。3.4 搜索过滤、批量操作与“非侵入”设计搜索功能很像软件包管理器应有的样子输入关键词实时匹配 formula 和 cask结果区分“已安装”和“未安装”未安装的可以直接点安装。搜索走的是远端 API查询速度取决于网络所以我加了 300ms 的防抖同时也支持先查本地缓存再异步去远端补充信息。批量操作是最需要克制的地方。技术上我可以让用户勾选 50 个包一次性点升级但我不会这么设计。队列的串行执行已经保证了稳定如果用户在界面上看到 50 个任务同时挂着意义不明反而可以在每个任务完成后局部刷新对应包的状态其余不受影响。这个“带反馈的批量操作”体验比那种统一的 loading 转圈要舒服得多。“非侵入”是我在做 UI 设计时给自己的一个准则BrewUI 不应该让用户觉得自己在操作一个复杂的命令行工具而是像在用系统自带的软件管理界面。按钮文案要清楚比如“升级”“移除”“重新安装”操作前要有确认弹窗危险操作比如卸载会连带影响其他包的包要先用醒目的颜色提示。真正做到“不懂 brew 的人也能安全使用”。4. 实操过程记录从初始化到打包分发4.1 环境准备与项目初始化开发 BrewUI 的机器是一台 macOS 13 的 Apple Silicon MacBookXcode 命令行工具齐全Homebrew 已经装好Node 用的是 20 LTS。项目初始化直接用了npm create electron-vite的 React TypeScript 模板这个模板内置了主进程、预加载脚本、渲染进程的三层结构省去了自己手动配置 Webpack/Vite 和 Electron 的繁琐步骤。npm create electron-vitelatest brewui -- --template react-ts cd brewui npm install electron-builder --save-dev npm install shell-quote electron-store选 electron-vite 模板还有一个原因它默认就能很好地处理开发环境和打包环境的差异。开发时渲染进程跑在 Vite 的 Dev Server 上主进程改动会触发 Electron 自动重启打包时用 electron-builder 统一产出 dmg 和 zip不用额外写复杂的脚本。4.2 目录结构与模块划分项目目录结构决定了我后续能走多快所以我刻意把“和 brew 相关的逻辑”和“Electron 壳子相关的逻辑”分开brewui/ ├── src/ │ ├── main/ │ │ ├── index.ts # 主进程入口创建窗口、注册 IPC │ │ ├── brew.ts # BrewRunner、命令队列、日志事件 │ │ ├── brewApi.ts # 对 brew 命令的高层封装install/uninstall/upgrade │ │ ├── sudo.ts # sudo 密码的安全获取和传递 │ │ └── store.ts # electron-store 封装存配置和缓存 │ ├── preload/ │ │ └── index.ts # contextBridge 暴露安全的 API │ ├── renderer/ │ │ ├── src/ │ │ │ ├── components/ # FormulaList、CaskList、DependencyTree 等 │ │ │ ├── hooks/ # useBrewList、useOutdated 等 │ │ │ ├── store/ # zustand 全局状态 │ │ │ └── App.tsx │ │ └── index.html ├── resources/ │ └── icon.png └── electron-builder.ymlpreload 脚本是渲染进程和主进程之间的唯一通道。我通过contextBridge暴露一组白名单 API例如window.brew.listInstalled()、window.brew.install(name)等渲染进程拿不到 Node 的任何能力只能调用这些方法。这不仅是安全最佳实践也能让代码边界清楚界面层永远不会出现require(child_process)这种坏味道。4.3 核心代码实现列表数据获取。我封装了一个getInstalledFormulas方法读取 JSON 后转换成内部类型// src/main/brewApi.ts import { execFile } from child_process; import { promisify } from util; const execFileAsync promisify(execFile); const BREW /opt/homebrew/bin/brew; // Apple Silicon 默认路径 export async function getInstalledFormulas() { const { stdout } await execFileAsync(BREW, [info, --jsonv2, --installed], { maxBuffer: 1024 * 1024 * 20, env: { ...process.env, PATH: /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin }, }); const json JSON.parse(stdout); return json.formulae as BrewFormula[]; }Apple Silicon 的 Homebrew 前缀默认是/opt/homebrewIntel Mac 则是/usr/local我封装了一个getBrewPath()来做自动探测检查这两个常见路径哪个存在同时也支持用户从设置里手动指定。安装与升级。通过 IPC 交互时渲染进程调用window.brew.install(wget)主进程把任务塞进 BrewRunner任务开始后通过mainWindow.webContents.send(brew:log, line)实时推日志// preload/index.ts contextBridge.exposeInMainWorld(brew, { install: (name: string) ipcRenderer.invoke(brew:install, name), uninstall: (name: string) ipcRenderer.invoke(brew:uninstall, name), upgrade: (name: string) ipcRenderer.invoke(brew:upgrade, name), onLog: (callback: (line: string) void) { const listener (_e: IpcRendererEvent, line: string) callback(line); ipcRenderer.on(brew:log, listener); return () ipcRenderer.removeListener(brew:log, listener); }, });依赖图构建。在brewApi.ts里维护一个dependencyGraph对象// src/main/dependencyGraph.ts interface Graph { nodes: Setstring; edges: Mapstring, string[]; // parent - children } export function buildGraph(formulas: BrewFormula[]) { const graph: Graph { nodes: new Set(), edges: new Map() }; for (const f of formulas) { graph.nodes.add(f.name); for (const dep of f.dependencies ?? []) { if (!graph.edges.has(f.name)) graph.edges.set(f.name, []); graph.edges.get(f.name)!.push(dep); graph.nodes.add(dep); } } return graph; } export function getDependents(graph: Graph, name: string) { const result: string[] []; for (const [parent, children] of graph.edges.entries()) { if (children.includes(name)) result.push(parent); } return result; }4.4 打包分发与 electron-builder 配置打包配置我放在electron-builder.yml里关键点是如何正确带上资源文件和图标。BrewUI 本身不打包任何 brew 二进制它是在用户已装 Homebrew 的机器上运行的因此安装包可以做得相对小主要就是 Electron 运行时加应用代码。appId: com.brewui.app productName: BrewUI directories: output: release files: - out/**/* - resources/**/* mac: category: public.app-category.developer-tools target: - dmg - zip icon: resources/icon.png dmg: contents: - x: 130 y: 220 - x: 410 y: 220 type: link path: /Applications打包命令很简单npm run build npm run dist。产物会在release目录下生成一个 dmg用户挂载后把 BrewUI 拖到 Applications 里就行。注意macOS 对未签名或未公证的应用有 Gatekeeper 限制首次打开需要在“系统设置 - 隐私与安全性”里手动允许。如果你要分发到更广的范围建议注册 Apple Developer 账号做签名和 notarization这一步不能省否则用户会卡在“已损坏”的提示上。4.5 快速体验方式如果你只想先体验一下 BrewUI 的感觉其实不用打包直接跑开发模式就行npm install npm run dev这个命令会启动 Electron 窗口加载 Vite Dev Server。第一次打开它会扫描已安装的 formula 和 cask界面上的“已安装”“可升级”列表很快就能渲染出来。此时可以试着搜索几个没装的包、点一下安装按钮观察底部的日志面板如何实时显示 brew 的输出这个体验和最终打包后的版本完全一致。5. 常见问题与排查技巧实录5.1 GUI 应用里 brew 命令找不到这是最经典的问题我一开始也没意识到。macOS 上通过 LaunchServices 启动 GUI App 时继承的环境变量和终端里完全不一样PATH通常只有/usr/bin:/bin:/usr/sbin:/sbin而 Homebrew 的路径在/opt/homebrew/bin或/usr/local/bin所以spawn(brew, ...)会直接报spawn brew ENOENT。解决方案是不要在代码里依赖系统 PATH而是显式探测并拼接。我写了一个getBrewPath()方法返回一个绝对路径比如/opt/homebrew/bin/brew同时把/opt/homebrew/bin:/usr/local/bin塞进子进程的 env.PATH。这个坑给了我很深的教训GUI 应用的运行环境不等于 shell 环境凡是依赖外部命令的应用都要显式指定路径不能假设环境变量一定存在。5.2 sudo 密码无法传入 brew 子进程前面提到过cask 安装到系统级目录时需要管理员权限。终端里跑brew install --cask xxx时sudo 能通过/dev/tty读取用户输入的密码但在 GUI 应用里spawn 出来的子进程没有 ttysudo 读不到任何输入命令会卡在密码提示界面日志看起来像是“死掉了”。我的解决办法是先通过一个模态窗口让用户输入管理员密码然后用spawn(sudo, [-S, --, ...])的方式把密码写进 stdin执行完成后立刻清空对应内存。实际使用中还有一个安全细节sudo -S 读取 stdin 的第一行作为密码剩下的行才会传给目标命令。这个顺序必须小心处理不然密码会被当成命令参数传给 brew造成严重的安全事故。因此我在实现时单独用小脚本测试了各种输入组合确保密码不会混入后续命令。如果实在不想处理 sudo 流程也可以要求用户提前在终端里执行一次brew install --cask --verbose xxx或者用 osascript 弹系统对话框输入密码但这样体验会打折。好在brew自带的“特权命令”大多可以用sudo -n加上缓存凭据的方式来规避重复输入在用户已经通过图形化授权过一次的情况下短暂时间内再次使用 sudo 不会重复弹窗。5.3 Intel 与 Apple Silicon 路径差异Homebrew 在两种芯片架构下的安装路径完全不同Intel Mac 通常是/usr/localApple Silicon 是/opt/homebrew。这看起来只是一个小路径判断但影响面很大不仅 brew 二进制的位置不同Cellar、Caskroom、tap 的路径也全不同。如果程序只在/opt/homebrew找 brew旧 Intel 机器上就会直接报不存在。我的建议是做双路径探测同时提供设置页让高级用户手动指定。还要注意一种更隐蔽的情况Rosetta 模式下运行的 Intel 版 Homebrew路径是/usr/local但它和原生 ARM 环境共享同一个 GUI 进程时可能会出现“同一个机器有两个 brew”的状态。BrewUI 会把这些信息显示在“系统信息”面板方便用户识别当前上下文。5.4 Homebrew JSON API 变更导致列表空白Homebrew 的--jsonv2输出格式相对稳定但不代表永远不变。比如有一段时间brew list --cask --jsonv2的字段结构和brew info --jsonv2并不完全一致如果你用一套解析逻辑去处理两处数据字段名对不上列表就会空白或者报错。我的方法是给每个 JSON 解析函数写独立的类型断言和空值兜底宁可某个字段显示为“未知”也不能因为一个字段缺失而让整页崩溃。同时我在启动时把 JSON 的 schema 版本号记下来一旦发现 brew 输出里新增了标记字段就触发一次“数据结构校验”用本地日志提醒开发者查看是否有格式变更。做这种工具的心里要时刻有数上游命令行工具的格式不保证长期兼容代码里必须预留容错空间。5.5 常见问题速查表现象可能原因解决方案列表为空控制台报 ENOENT未找到 brew 可执行文件检查 getBrewPath 是否正确尝试手动指定路径操作卡在 “需要管理员密码”spawn 子进程没有 tty使用 sudo -S 配合图形化密码输入或提示用户预授权升级很慢甚至一直转圈每次都触发 brew update改用 brew outdated只在手动刷新时执行 update格式化大量包时界面卡死渲染进程一次性处理过多 DOM使用虚拟滚动列表限制一次性渲染节点数部分软件显示已安装但打不开cask 安装的是 .pkg 或需要额外配置在详情面板展示 caveats 和 artifact 信息Jenkins/CI 环境无法使用CI 里没有图形会话增加 headless 模式只提供 CLI 调用和 JSON 输出还有一些细节我想单独提醒日志面板不要无限增长超过一定行数就截断操作按钮在任务进行中要统一 disable避免用户同时点多个操作造成队列混乱卸载有依赖关联的包之前一定要先展示“下列包也依赖了它”的警告不然用户很容易无意识拆掉半套环境。这些都是我在真实使用中一点点补上的血泪经验。做这个项目最深的体会是工具类应用的护城河不在 UI 多炫酷而在“使用它的过程中用户会不会觉得安全、可控、不焦虑”。BrewUI 从第一版只能看列表到后来能装能卸、能看依赖、能处理权限每一步都来自真实需求。最后再分享一个小技巧如果你也想做类似的包管理 GUI建议一开始就把所有 brew 相关命令收敛到一个模块里不要散落在各个业务逻辑中这样即使 Homebrew 的命令格式变了你也只需要改这一个文件而不是翻遍整个代码库。BrewUI 后续还可以扩展的方向包括 brew services 的管理界面、自动清理缓存的功能、以及一键生成维护仓库用的 Brewfile这些都是顺手就能加进去的新大陆。