1. 项目概述与需求拆解1.1 BrewUI 到底解决什么问题先说个我自己的经历。有段时间帮几个不太熟命令行的朋友配开发环境每次都得远程指导他们敲brew install、brew services start这类命令。明明 Homebrew 已经是 macOS 上最主流的包管理器了但命令行三个字本身就是一道门槛很多人一看到终端窗口就发怵。后来我就想能不能给 Homebrew 套一个图形界面让装包、卸包、查依赖、管服务这些高频操作变成点鼠标就能完成的事这就是我理解中 BrewUI 这类项目最核心的价值——把命令行工具的能力以 Web 界面的形式暴露出来降低使用门槛。BrewUI 本质上是一个围绕 Homebrew 的 Web 管理面板。它不是一个从零发明的包管理器而是把 Homebrew 这一底层引擎包了一层壳通过调用 brew 命令获取数据、执行操作再在前端以可视化的方式呈现。打个比方Homebrew 是发动机BrewUI 是方向盘和仪表盘你不需要打开引擎盖去摆弄零件看着仪表盘就能知道车况转动方向盘就能控制方向。适合参考或直接使用 BrewUI 这类方案的人我总结下来有三类一是刚接触 macOS 开发、对终端不熟的新手图形界面能减少挫败感二是需要在多台 Mac 上维护开发环境、但不想反复记忆命令的开发者三是团队内部做开发机统一管理、希望给非技术人员提供自助安装入口的运维或技术负责人。1.2 核心功能边界与设计目标一个合格的 BrewUI 项目功能边界应该画在哪这是我拆解这个项目时最先想到的问题。如果什么功能都往里塞最后会变成一个四不像。对比了社区里常见的几个同类方案再结合 Homebrew 本身的能力模型我认为 BrewUI 的 MVP最小可用版本应该聚焦在四件事上包的搜索、安装、升级、卸载这是最高频的操作界面要突出搜索框安装/升级/卸载的按钮要一眼可见。已安装包和依赖关系的可视化用户最怕装了这个会不会破坏别的东西一张依赖关系图能省去大量解释成本。服务的启停管理brew services是很多后端开发者每天都要用的命令Web 界面里做几个开关按钮非常实用。更新提醒与系统信息概览首页显示 brew 版本、系统版本、可升级包的数量让用户打开面板就心里有数。设计目标上我的建议是一句话界面的复杂度永远不要超过命令行的复杂度。BrewUI 的定位是让操作更简单不是把简单的事情搞得更复杂。所以每一个按钮、每一个开关背后都应该能对应到一条明确的 brew 命令用户看完前端操作能脑补出后端执行了什么这才是好的设计。另外一个容易忽略的点是权限模型——brew 有些操作需要 sudoWeb 服务如果跑在低权限用户下就得想清楚怎么处理。这个问题后面实操章节我会详细讲。2. 技术选型与架构思路2.1 为什么我不建议用 Python 写后端搜 BrewUI 相关讨论的时候不少人第一反应就是 Python 的 Flask 或 FastAPI 套个前端完事。这个思路不是不行但有几个隐性问题。首先是进程管理和系统交互的天然契合度BrewUI 本质是个执行器它要做的核心事情是启动子进程跑 brew 命令、解析输出、管理生命周期。Node.js 的child_process和 Go 的os/exec在这块都相当顺滑尤其是流式输出处理——安装一个大包时前端要实时显示进度条就需要后端把 stdout 一行一行推给前端而不是等整个命令跑完再一次性返回Node 的流式处理非常自然。其次Homebrew 本身是 Ruby 写的但它对外暴露的就是命令行接口。Python 调用 subprocess 也能做但如果你考虑后续要打包成桌面应用比如用 Electron 或 Tauri 套壳那前后端同构或者统一在 JS/TS 生态里会省事很多。我个人经验是个人项目或小团队工具选最顺手的技术栈但一定要把进程管理和流式输出这两个能力放在第一优先级。所以我会选 Node.js TypeScript 做后端前端用 Vue 3 或 React 都行重要的是前后端通过 WebSocket 通信实现实时进度反馈。2.2 整体架构的四个关键决策架构设计上有四个关键决策直接决定了项目能不能稳定跑起来。第一后端必须以命令执行器为核心而不是数据库模型为核心。很多 Web 项目第一步就是建表但 BrewUI 的数据源是实时的 brew 命令输出不是数据库。项目里可以有一个轻量的 SQLite 存操作日志、用户偏好之类的元数据但包列表、依赖关系、版本信息这些必须每次实时从 brew 拉取否则会面临数据不一致的问题。比如你在终端手动装了一个包Web 界面如果不重新执行brew list展示的还是旧数据用户就会困惑。第二命令执行必须排队不能并发。brew install和brew upgrade这类操作往往需要获取锁同时跑多个会报Another active Homebrew process is already running的错误。所以后端要实现一个简单的任务队列同一时间只允许一个 brew 操作在执行其余的进队列等待。这个用 Node 的p-queue库或者自己写一个数组就能实现但很多人第一次做会忽略导致实测时各种莫名其妙的冲突。第三输出解析要按 Homebrew 的 ANSI 转义码做清洗。brew 在终端里输出是带颜色的会有\x1b[32m这类 ANSI 转义序列直接塞到 WebSocket 里给前端展示前端会显示一堆乱码。所以后端要做一层清洗把 ANSI 码剥掉只留纯文本和结构化信息。这一层虽然不起眼但用户体验差别巨大——谁也不想看日志时满屏都是[32m。第四sudo 密码处理要前置设计。brew 的services操作有时需要管理员权限Web 服务如果跑在普通用户下执行 sudo 命令会卡在密码输入上。我的建议是别在 Web 界面里搞输入密码这种交互太危险了。要么把 Web 服务本身配置成无需密码就能执行特定 brew 命令用 sudoers 精细控制要么在文档里明确要求用户预先在终端做好授权。这个属于安全的取舍后面我细说。3. 实操搭建从零实现 BrewUI 核心功能3.1 项目初始化与环境准备开始动手之前先确认你的环境macOS 系统已经装好 Homebrew 和 Node.js 18。Node 版本太老的话很多新语法和 WebSocket 库会报错建议直接装 LTS 版本。前端我用 Vue 3 Vite后端用 Node.js TypeScript数据库用 SQLite通过 better-sqlite3这组合灵活度够高也方便以后扩展。先建目录结构mkdir brewui cd brewui mkdir server client cd server npm init -y npm install typescript ts-node types/node express ws better-sqlite3 node-pty npm install -D types/ws types/express types/better-sqlite3这里我特意加了node-pty它可以在 Node 里模拟一个伪终端来执行命令。用普通child_process.exec也能执行命令但会有个问题——brew 安装大软件包时输出会走管道缓冲进度条更新是顿挫的而node-pty能模拟真实的终端交互输出更平滑还能处理一些需要 TTY 的交互场景。代价是依赖原生编译如果安装失败可以用child_process.spawn顶替功能上没问题体验稍差一点。前端的初始化我就不展开了npm create vitelatest client -- --template vue一行命令的事。核心依赖就两个socket.io-client负责 WebSocket 通信element-plus做 UI 组件库。Element Plus 的表格、标签、按钮都现成能少写很多样式。3.2 后端核心代码命令执行器与任务队列这是整个项目的灵魂部分我直接贴核心代码并逐段解释。先看命令执行器。核心思路是创建一个统一的入口函数所有的 brew 操作都从这里过// server/src/executor.ts import { spawn, type ChildProcessWithoutNullStreams } from child_process; import { EventEmitter } from events; import { WebSocket } from ws; class BrewExecutor extends EventEmitter { private queue: Array{ id: string; command: string; args: string[] } []; private running false; private currentProcess: ChildProcessWithoutNullStreams | null null; // 清洗 ANSI 转义码保留纯文本 private stripAnsi(text: string): string { // eslint-disable-next-line no-control-regex return text.replace(/\x1b\[[0-9;]*[a-zA-Z]/g, ); } // 向所有前端客户端广播执行输出 private broadcast(event: string, data: unknown) { this.emit(event, JSON.stringify({ event, data })); } // 将任务加入队列并尝试消费 enqueue(id: string, command: string, args: string[]) { this.queue.push({ id, command, args }); this.broadcast(queue_update, { queueLength: this.queue.length }); this.consume(); } private async consume() { if (this.running || this.queue.length 0) return; this.running true; const task this.queue.shift()!; await this.runTask(task); this.running false; this.consume(); // 继续执行下一个任务 } private runTask(task: { id: string; command: string; args: string[] }) { return new Promisevoid((resolve) { this.broadcast(task_start, { id: task.id, command: ${task.command} ${task.args.join( )} }); const proc spawn(task.command, task.args, { env: { ...process.env, ...this.getBrewEnv() }, }); this.currentProcess proc; proc.stdout.on(data, (chunk: Buffer) { const text this.stripAnsi(chunk.toString()); this.broadcast(task_output, { id: task.id, output: text }); }); proc.stderr.on(data, (chunk: Buffer) { const text this.stripAnsi(chunk.toString()); this.broadcast(task_output, { id: task.id, output: text }); }); proc.on(close, (code) { this.broadcast(task_end, { id: task.id, code }); this.currentProcess null; resolve(); }); }); } // 获取 Homebrew 的环境变量特别是 PATH private getBrewEnv(): Recordstring, string { // 常见 Homebrew 安装路径Apple Silicon 和 Intel 不同 const linuxbrewPaths [ /opt/homebrew/bin, // Apple Silicon /usr/local/bin, // Intel ]; const path ${linuxbrewPaths.join(:)}:${process.env.PATH || }; return { PATH: path }; } // 执行一次性命令不走队列比如查询类 execNow(command: string, args: string[]): Promise{ code: number | null; output: string } { return new Promise((resolve) { const proc spawn(command, args, { env: { ...process.env, ...this.getBrewEnv() }, }); let output ; proc.stdout.on(data, (chunk: Buffer) { output this.stripAnsi(chunk.toString()); }); proc.stderr.on(data, (chunk: Buffer) { output this.stripAnsi(chunk.toString()); }); proc.on(close, (code) resolve({ code, output })); }); } } export const brewExecutor new BrewExecutor();有几个细节值得展开。getBrewEnv这个函数是踩坑踩出来的——很多 RunUI 类的项目跑不起来不是代码逻辑问题而是执行brew命令时找不到brew可执行文件。因为 Web 服务通过 launchd 或直接node启动时PATH 环境变量可能没有被正确加载特别是 Apple Silicon 上 Homebrew 装在/opt/homebrew/bin这个路径默认不在系统 PATH 里。所以在所有 spawn 调用里显式指定 PATH是保证找得到 brew的关键。execNow函数是我后来加的专门处理那些查询类命令比如brew list --formula、brew info --json。这类命令没有副作用不需要排队执行完就返回结果。如果把查询操作也扔进队列那用户在安装一个大包时想看列表就得干等安装结束体验很差。所以设计上是写操作排队读操作并行既保证安全又保证响应速度。3.3 WebSocket 服务与前端实时交互服务端用 WebSocket 推送状态前端实时渲染。这里我用原生ws库而不是 Socket.IO原因就是少一层抽象协议更简单调试更直接。前端连上之后后端把所有事件广播出去前端根据event字段分流处理。// server/src/server.ts import express from express; import { createServer } from http; import { WebSocketServer } from ws; import { brewExecutor } from ./executor; import { runBrewCommand } from ./routes; const app express(); const server createServer(app); const wss new WebSocketServer({ server }); app.use(express.json()); // REST 接口——查询类 app.get(/api/packages, async (req, res) { const result await runBrewCommand(list, [--formula, --json]); res.json(JSON.parse(result.output)); }); app.get(/api/casks, async (req, res) { const result await runBrewCommand(list, [--cask, --json]); res.json(JSON.parse(result.output)); }); app.post(/api/install, (req, res) { const { formula } req.body; const taskId ${Date.now()}-${Math.random().toString(36).slice(2, 8)}; brewExecutor.enqueue(taskId, brew, [install, formula]); res.json({ taskId }); }); app.post(/api/uninstall, (req, res) { const { formula } req.body; const taskId ${Date.now()}-${Math.random().toString(36).slice(2, 8)}; brewExecutor.enqueue(taskId, brew, [uninstall, formula]); res.json({ taskId }); }); // WebSocket 广播 wss.on(connection, (ws) { const send (data: string) ws.readyState ws.OPEN ws.send(data); brewExecutor.on(event, send); ws.on(close, () brewExecutor.off(event, send)); }); server.listen(3000, () console.log(BrewUI server running on http://localhost:3000));前端这块核心逻辑是维护一个tasks响应式对象每个任务有id、command、status、output四个字段。WebSocket 收到task_output事件时就找到对应任务把 output 追加到日志区。Vue 3 的reactive会自动追踪修改并更新 DOM所以前端代码非常简洁。有个前端展示的小技巧日志区要自动滚动到底部但是不能每次都滚——因为用户可能想回看之前的输出。我的方案是监听滚动位置如果用户已经在底部附近比如距底部小于 30 像素就自动滚动否则不动。这个交互细节很影响体验不加的话安装过程中用户一往上翻历史日志就会被强制拉回底部非常恼火。3.4 服务的启停管理模拟终端执行brew services 这块用child_process.spawn会遇到一个棘手问题brew services start在终端运行时输出带有颜色而且进程可能不会主动退出表现为启动后挂起。之所以挂起是因为 brew services 启动服务后终端里返回控制权的方式依赖 TTY 的交互。所以这里我用node-pty起一个真正的伪终端// server/src/services.ts import * as pty from node-pty; export function startService(formula: string): Promisestring { return new Promise((resolve, reject) { const term pty.spawn(/opt/homebrew/bin/brew, [services, start, formula], { name: xterm-color, cols: 80, rows: 30, env: process.env as Recordstring, string, }); let output ; term.onData((data) { output data; // 判断命令是否已执行完毕出现特定标志或等待超时 if (output.includes(successfully started) || output.includes(already started)) { term.kill(); resolve(output); } }); term.onExit(() resolve(output)); // 8 秒超时保护防止 pty 卡死 setTimeout(() { term.kill(); resolve(output); }, 8000); }); }这段代码的思路是用伪终端执行命令监听输出一旦出现成功标志或者超时就结束伪终端返回结果。brew services stop和restart的逻辑完全一样只是参数不同可以抽成一个通用函数。这个模块调通之后在界面上放一组开关按钮状态映射到brew services list的输出来判断用户点击切换体验非常顺滑。4. 前端界面与交互设计4.1 主面板包管理页的设计逻辑界面设计的原则是少即是多。我并没有做一个花哨的仪表盘而是把最核心的包管理做成一个带搜索框的表格页。表头就是三列包名、已安装版本、最新版本。顶部是搜索框和刷新按钮行右侧是卸载按钮。这个设计足够应对日常 90% 的场景。版本信息怎么获取brew list --formula --json会给已安装版本brew outdated --json会给可升级包和最新版本。前端拿到两个接口的数据后做一次合并就能在表格里同时展示当前版本和最新版本。当最新版本和当前版本不一致时行内显示一个升级按钮背景色稍微突出一下。这个逻辑简单直接但视觉上很直观——有没有东西要更新一眼就能看到。搜索功能我建议在前端做而不是每次请求都打到后端。因为包列表最多也就几百条前端filter一次性能毫无压力。但搜索框要支持模糊匹配和正则比如输入py既要有python也要有python3同时还要有pytorch一个大小写不敏感的includes就够了。搜索的交互细节上我加了 300ms 的防抖避免用户每敲一个字母就触发一次过滤造成卡顿感。4.2 详情页依赖关系树展示包详情页是 BrewUI 的加分项。用 Element Plus 的el-tree组件把依赖关系渲染成树形表格。根节点是当前包子节点是它的依赖再往下展开是依赖的依赖。这个树的数据从哪来brew info --jsonv2 formula的返回结果里有dependencies数组里面是直接依赖的名字。递归查询每个依赖的brew info就能构建出一棵完整的依赖树。需要注意的是递归查询可能产生循环依赖A 依赖 BB 又依赖 A所以代码里必须维护一个已访问集合遇到环就停止递归。// server/src/dependency.ts import { runBrewCommand } from ./routes; async function buildDependencyTree(formula: string, depth 0, visited new Setstring()): PromiseDependencyNode { if (visited.has(formula)) { return { name: formula, depth, cycle: true, children: [] }; } visited.add(formula); const { output } await runBrewCommand(info, [--jsonv2, formula]); const info JSON.parse(output); const dependencies info.formulae[0]?.dependencies || []; const children: DependencyNode[] []; for (const dep of dependencies) { children.push(await buildDependencyTree(dep, depth 1, visited)); } return { name: formula, depth, cycle: false, children }; }这个树放在详情页的意义不是为了炫技而是让用户装之前心里有数。很多人在终端里brew install xxx时看到Processing ... dependency根本不知道那是什么东西。有了依赖树点开详情就能看清这个包会带上哪些小弟这些小弟又分别是什么用途。对强迫症患者和谨慎型用户来说这个功能极大缓解装了会不会搞坏环境的焦虑。4.3 服务管理与日志实时查看服务管理页就是一个卡片列表每个服务一张卡片显示服务名、当前状态绿色运行中/灰色已停止、启动/停止切换开关。这个页面的逻辑特别简单但视觉反馈要做足——点击开关瞬间按钮进入 loading 状态等后端返回成功后再切换状态如果失败就弹提示并恢复原状。日志查看我做了个独立页面功能类似tail -f。实现上就是 WebSocket 订阅brew services log name的输出流前端维护一个环形缓冲区最近 500 行日志保留在内存中超过就丢弃最旧的。这个环形缓冲的设计有个好处即使日志量大页面内存占用也不会失控。为了调试方便我在日志面板上放了一个下载完整日志按钮点击后向后端发一个请求后端执行brew services log name /tmp/brewui-name.log然后把文件路径返回给前端前端用浏览器下载。这个小功能在排查服务启动失败问题时非常有用。5. 常见问题与避坑实录5.1 brew 命令执行慢或超时这是我实操中被问得最多的一个问题。BrewUI 界面上某些操作转圈圈很久才有响应通常是这几个原因brew update 自动检查Homebrew 每次执行命令前会自动检查是否有新版本这个检查可能耗时几秒甚至几十秒特别是网络不好的时候。解法是设置环境变量HOMEBREW_NO_AUTO_UPDATE1禁用自动检查改为在界面上放一个手动更新 brew 本体的按钮。Lock 文件残留brew 的锁文件在/opt/homebrew/var/homebrew/locks目录下。如果之前有终端里的 brew 进程被异常终止比如拔电源锁文件会残留导致后续命令一直等待。排查方法是看有没有.lock文件有就手动删掉。网络代理问题如果你本机开了一些网络代理brew 的请求可能会被代理拦截导致安装超时。这个得根据个人环境去排查界面上很难定位所以我建议在安装任务开始时记录时间戳方便对比慢到底慢在哪个阶段。5.2 WebSocket 连接不稳定前端频繁断线重连这个问题我排查了很久最后发现和内核的 fd 限制有关。WebSocket 连接本身很轻量但每个连接对应一个文件描述符。如果你频繁刷新页面或者多个标签页同时开着 BrewUIfd 消耗会快速上涨。当进程的 fd 数超过系统默认上限macOS 是 256 或 1024新的连接就会被拒绝。解法是在启动前端开发服务器时增加 Node 进程的资源限制ulimit -n 4096 npm run dev后端如果也要处理大量连接这个值可以调得更高。另外生产环境建议用 Nginx 反代 WebSocket并开启连接空闲超时保护——默认的proxy_read_timeout是 60 秒WebSocket 长连接会被 Nginx 掐断得改成比如 3600 秒或者更大。5.3 权限问题的处理brew 的服务操作比如启动 MySQL、PostgreSQL需要向系统的 LaunchAgent 写入 plist 文件这些文件落在用户目录或者/Library/LaunchDaemons下需要管理员权限。我踩过的坑是Web 服务跑在 launchd 启动的常驻进程里用户是普通账号执行brew services start mysql时报错Permission denied。后来我总结了两个可行的方案方案一让 Web 服务以当前用户身份运行安装命令不用 sudo。Homebrew 装包本身不需要 sudo只有服务类操作才会有权限问题。在界面上对服务操作单独做标记点击时先向后端发一个探测请求检查是否有权限没有就弹出提示让用户去终端执行sudo brew services start xxx。这个方案最安全也最简单。方案二配置 sudoers 白名单让特定用户无需密码就能执行brew services相关命令。在/etc/sudoers.d/brewui里加一行youruser ALL(ALL) NOPASSWD: /opt/homebrew/bin/brew services *。这样后端可以安全地执行sudo brew services start xxx而不会卡在密码提示。注意这个方案有安全风险只建议在可信的本地环境或内网环境使用千万不能暴露到公网。我个人的建议是方案一优先方案二作为进阶配置。BrewUI 这种工具本来就是个人开发机管理工具没必要为了少敲一次密码引入一个需要写 sudoers 的复杂度。5.4 前端页面刷新后状态丢失这个问题说起来有点低级但真的很容易犯。用户在安装页点了一个安装任务然后刷新页面任务状态全没了而且后端还在后台继续执行。等任务执行完WebSocket 推过来的事件因为没有对应的前端任务对象直接被丢弃了。解法是在 WebSocket 连接建立时后端先推送一份当前正在执行的任务快照。前端收到快照后重建任务列表再继续接收后续的增量事件。实现上也不复杂后端在任务队列里维护一个activeTasks数组event事件里带上完整的快照数据前端做一次全量替换兼顾简单和正确性。这个细节不做的话用户刷新一次页面就丢一次进度反馈心理体验非常差。6. 安全加固与部署建议6.1 不要让 BrewUI 暴露在公网先说一句重话BrewUI 这类工具是给本机或可信局域网用的不是给公网用的。因为它的本质是执行任意 brew 命令而 brew 命令的能力边界远超普通 Web 应用——一个恶意请求可能触发安装恶意包、卸载系统组件甚至通过brew的某个命令组合扩展到任意代码执行。这是我在项目 README 里用加粗大字写的警告。如果确实有局域网访问需求比如两台 Mac 之间远程管理我的建议是加一层简单的 token 认证后端在请求头里校验一个预先配置的 token。用 Nginx 做 HTTPS 反代避免明文传输。绑定内网 IP不要监听 0.0.0.0。server { listen 8443 ssl; server_name brewui.local; ssl_certificate /etc/ssl/brewui.crt; ssl_certificate_key /etc/ssl/brewui.key; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 3600s; } }6.2 进程守护与自动重启本地开发的时候node server.js直接跑就行。但如果你想让 BrewUI 常驻后台最好用 launchd 或者 pm2 做进程守护。launchd 是 macOS 原生的守护机制写一个 plist 文件放到~/Library/LaunchAgents下即可。注意 plist 里的EnvironmentVariables要配置正确的PATH否则你会发现 launchd 启动的服务找不到brew命令。用 pm2 则更简单pm2 start server.js --name brewui一行命令搞定它还自带日志管理和自动重启能力。我个人偏好 pm2因为它能直接看到内存占用和重启次数排查问题方便很多。6.3 数据备份与日志轮转BrewUI 本身不存太多业务数据但 SQLite 里存的操作日志、偏好设置还是有备份价值的。用better-sqlite3的backupAPI 就能做在线热备不用停服务。日志文件建议每天轮转一次用 launchd 的StartCalendarInterval或者 pm2 的 logrotate 模块都可以避免日志文件无限膨胀占满磁盘。这一点在长期运行时尤其重要——我见过有人装完 BrewUI 不管半年后才发现日志已经吃掉了几 GB 磁盘而且里面全是 ANSI 乱码毫无可读性。7. 实测效果与扩展方向跑通核心功能之后我自己做了三件事来验证项目质量一是在一台一直开着 brew 自动更新的机器上连续跑了一周观察内存占用和任务队列稳定性二是让一个从没用过终端的朋友用 BrewUI 完成安装 Nginx、启动服务、配置开机自启整套流程记录他踩了哪些操作上的坑三是写了几个脚本模拟高频并发请求验证任务队列不会被冲垮。实测下来内存占用稳定在 80MB 左右任务队列在高并发下不会丢失任务WebSocket 断线重连后能恢复状态。朋友那边的反馈比较有价值他提出两个我之前没注意的点一是服务启动后需要一个打开配置文件的按钮可以直接跳转到编辑器二是安装完成后希望有通知声音提醒不然装大包时干等容易分心去做别的事。这两个需求后来我都加了都很简单但很提升幸福度。扩展方向上我觉得有两个值得做。第一个是brew bundle的支持——导入Brewfile就能一键还原整个开发环境这个对多台机器同步环境配置特别有用。第二个是集成通知服务比如安装完成后推送到微信或邮件适合远程跑任务时用。这两个方向都不复杂基于现有的命令执行器和任务队列框架大概两三天就能加上。BrewUI 这种工具最迷人的地方就在于它的能力天花板完全取决于你对 Homebrew 的理解——理解越深界面能提供的价值就越高。