BrewUI 这个名字我第一次看到是在 GitHub 上搜“brew 图形化客户端”时发现的。用 macOS 的同学应该都知道 Homebrew日常装个命令行工具、更新软件都得在终端里敲命令。BrewUI 是个很有意思的开源项目简单说就是给 Homebrew 穿上图形界面把装软件、更新软件、清理旧包这些操作变成鼠标点点点。它能解决的最大问题就是让不习惯终端的用户也能用上 Homebrew 的强大能力同时也让老手在管理一堆包时能省掉打字的功夫。我这个平时喜欢折腾各种开发工具的博主从下载源码编译到实际使用前前后后踩了不少坑这篇文章就把 BrewUI 从设计思路到实操细节完整拆一遍想省事的朋友可以直接照着参考。很多用 Homebrew 的人应该都有过这种体验一开始只是想在终端装个 ntfs 驱动或者 ffmpeg后面越装越多到最后输入brew list出来一长串包名自己都忘了装过什么。Homebrew 本身的设计就是面向命令行操作它的安装日志、版本信息、依赖关系全都通过文本输出对新手非常不友好。BrewUI 的思路不是重新发明一套包管理机制而是把brew这个命令背后的能力封装成图形化界面搜索包、查看包详情、一键安装、一键升级、清理旧版本这些都是最常见的场景。这个项目适合几类人一类是完全不熟悉终端但需要装 Homebrew 软件的普通用户另一类是在 macOS 上做开发希望有一个更直观的工具来管理全局环境的技术人员还有一类是自己想写点 macOS 原生 App想看看别人是怎么调用 Homebrew CLI 做前端展示的开发者。无论你是哪一类读完这篇文章后基本可以自己去编译一个 BrewUI把日常包管理任务从全命令行切换到图形界面。1. 内容整体设计与思路拆解1.1 Homebrew 的痛点与图形化的价值先聊聊 Homebrew 本身的问题。它作为 macOS 上事实标准的包管理器靠的是一个个命令和选项比如brew search、brew install、brew upgrade、brew cleanup每次都要手动输入包名而且输出信息量很大。终端里经常出现一堆 Downloading...、 Pouring...、 Caveats这样的提示对小白来说很难分辨哪些是警告、哪些是错误、哪些只是正常输出。更何况 Homebrew 还分为 tap、cask、service 这些概念只知道brew install curl的人不一定知道brew install --cask visual-studio-code可以装带界面的应用。BrewUI 把这一整套逻辑压缩成一个可视化的视图。主界面上分成已安装、可更新、搜索、Brewfile 几个区域每个包就是一个卡片或者一行列表显示当前版本、最新版本、是否 outdated、依赖了谁点进去能看到更详细的描述和依赖树。这样设计的价值不只是“好看”而是降低了认知负担。用户不需要记命令也不需要去网上搜命令行参数鼠标操作就能完成绝大多数事情。从体験上来说图形化还有一个好处它把终端里的长串输出变成了结构化的日志面板。安装一个包如果失败BrewUI 会把 brew 的 stderr 单独提取显示再配合退出码能在界面上明确告诉你这是网络问题、权限问题还是依赖冲突。这种信息分层方式比盯着滚动日志找Error:要高效得多。1.2 技术选型背后的考量我最初以为 BrewUI 这种项目会用 Electron 来做毕竟 Web 技术栈开发效率高换个窗口背景也方便。但实际看了它的仓库之后发现BrewUI 选的是原生 SwiftUI这个选择我仔细想了一下还是挺聪明的。Homebrew 本身是一个轻量级工具执行一次命令通常不会占用太多内存但如果用 Electron 包一层 Chromium启动就是几百 MB 内存这就违背了“轻量管理工具”的初衷。SwiftUI 跑在 macOS 上非常顺滑启动速度接近秒开界面风格和系统其他 App 完美统一而且可以直接调用系统 API 去获取路径、权限、通知等服务。另一个现实因素是BrewUI 这种项目定位就是给 macOS 用没必要跨平台Electron 的跨平台优势在这里没有意义。核心实现则没有去碰 Homebrew 的内部数据库而是老老实实调用brew这个 CLI 工具再解析它的输出。为什么这么做因为 Homebrew 的数据存储和内部结构并没有对外承诺稳定包括 Cellar、opt、Caskroom 这些目录路径会随版本变化自己直接去读文件系统很容易在升级 Homebrew 后挂掉。而brew命令本身提供了稳定的文本输出接口还支持--jsonv2这种结构化输出BrewUI 只要保证 brew 版本别太老就能一直兼容。这种“自己不碰底层只做前端包装”的思路对很多工具类 App 都有参考价值。1.3 模块怎么拆依赖怎么理看了几天代码BrewUI 的源码结构基本可以分成三层底层是 HomebrewCore负责调用 CLI、解析 JSON、管理任务队列中间是 ViewModel 层把底层数据转换成界面需要的状态比如包列表的排序、过滤、状态标记最上面是 SwiftUI 视图层只负责展示和用户交互。这种分层最大的好处是后续加新功能时不需要动底层协议。在底层BrewUI 设计了一个BrewCommand协议每个具体命令比如SearchCommand、InstallCommand、UpgradeCommand都实现同一个接口传参、执行、解析返回结果。这样一条新命令的接入成本就很低只需要写一个返回BrewOutput的结构体。任务队列用的是OperationQueue并设置最大并发数为 1保证同一时间只有一个 brew 进程在跑避免 Homebrew 自带的锁冲突。这个模块划分对我自己的项目也有启发不要把所有命令拼在一起做一个大块代码而是把每个操作抽成独立单位。这样调试时能快速定位是命令拼接的问题还是解析的问题。而且将来如果 brew 换了输出格式只需要修改对应命令的解析器不需要动界面代码。2. 核心细节解析与实操要点2.1 与 Homebrew CLI 的交互方式BrewUI 最核心的部分就是和 Homebrew CLI 的交互。用 Swift 写的话常见的做法是用Process来启动一个子进程把参数传进去然后捕获标准输出和标准错误。关键是环境变量因为 macOS 的图形程序默认 PATH 环境变量里没有/opt/homebrew/bin或/usr/local/bin直接调用时经常找不到brew命令。所以 BrewUI 一般不会直接用brew这个短命令而是先检测到 brew 的绝对路径再通过绝对路径去执行。一个简化的 Swift 调用示例大概长这样func runBrew(_ arguments: [String]) async throws - String { let process Process() let executablePath HomebrewLocation.currentPath // 例如 /opt/homebrew/bin/brew process.executableURL URL(fileURLWithPath: executablePath) process.arguments arguments var env ProcessInfo.processInfo.environment env[PATH] /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin env[HOMEBREW_NO_AUTO_UPDATE] 1 process.environment env let pipe Pipe() process.standardOutput pipe process.standardError pipe try process.run() let data pipe.fileHandleForReading.readDataToEndOfFile() process.waitUntilExit() return String(data: data, encoding: .utf8) ?? }这里有个很关键的参数HOMEBREW_NO_AUTO_UPDATE1。Homebrew 在执行很多命令时都会自动做brew update在网络慢的时候一个简单的brew install也会卡很久。GUI 程序本来就容易让用户觉得“没反应”如果每次点击安装都去更新仓库体验会很差。所以 BrewUI 会在普通操作时关掉自动更新只有在用户主动点“更新仓库”时才执行brew update。解析输出时BrewUI 优先用brew info --jsonv2获取包信息而不是直接解析brew list的文本。JSON 里包含包的版本号、已安装路径、依赖列表、caveats、cask 信息等字段结构很稳定。处理 JSON 时要注意大结果集比如brew info --jsonv2 --all会返回所有包的信息数据量非常大BrewUI 一般只会在“搜索”或“加载全部包”时才用一次请求之后把结果存在内存里做前端过滤避免每次输入关键字都去跑命令。2.2 并发控制和任务状态机Homebrew 在同一个机器上同时跑多个命令是有锁的比如你在终端窗口执行brew install同时 BrewUI 又发起一个brew upgrade后者会报Error: Another active Homebrew process。为了避免这个问题BrewUI 使用了串行队列每时每刻最多只有一个子进程在运行。但“串行”听起来简单做起来有一些细节。如果你的 UI 线程直接发起runBrew界面会卡死。正确做法是把任务放到OperationQueue里并且用async/await或者DispatchQueue让 UI 保持响应。任务执行期间要有一个状态机等待中、执行中、成功、失败、已取消。每次命令结束BrewUI 会根据退出码把当前任务从“执行中”切换到对应状态再通知主线程刷新列表。这里踩过的一个坑是用户点了某个包的“安装”按钮后如果任务还在排队用户又点了好几次会导致多个 InstallCommand 进队列。BrewUI 的做法是在 ViewModel 里维护一个“当前已排队的包 ID 集合”如果已经存在就不重复添加。另外还应该允许取消排队中的任务。Process 在任务取消时并不总能立即杀掉子进程尤其是brew upgrade这种耗时的操作直接调process.terminate()可能留下半成品。所以更好的做法是先修改标记等到 brew 进程结束再检查标记必要时再执行brew cleanup把临时文件清干净。2.3 界面设计里的实用细节BrewUI 的界面设计很克制没有把复杂功能全堆在首页。主界面就是一个左侧分类栏和右侧包列表分类栏里有“已安装”“可更新”“全部”“搜索”顶部是搜索框和刷新按钮。每个包在列表里显示五列包名、当前版本、最新版本、状态、操作按钮。状态有installed、outdated、not installed、pinned这几种会用不同颜色标签区分。比较惊喜的是搜索结果会实时分组把普通 formula 和 cask 分开并且显示每个包的简介。这个体验比终端里的纯文本搜索强很多尤其你想装一个图形软件但完全不记得名字的时候只要在搜索框输入“browser”或者“editor”所有相关的 cask 都会列出来。我个人建议用 BrewUI 搜索时多留意一下“描述”字段很多包名和实际作用并不完全对应。界面里还有一个细节安装日志面板是折叠式的默认不展开只有任务失败时才会自动弹出来。这样平时使用界面很清爽一旦出问题又可以直接看到那个包安装到哪一步挂了。日志面板支持复制选中内容后面排查问题非常有用。2.4 权限、安全和系统兼容性Homebrew 有两种常见安装路径Apple Silicon Mac 上是/opt/homebrewIntel Mac 上通常是/usr/local。这两种路径的权限策略不一样Apple Silicon 下创建 Homebrew 目录时就把所有权交给了当前用户绝大多数操作都不需要 sudo。而 Intel Mac 如果用了历史遗留的/usr/local有些目录可能是 root 所有安装时会提示权限不足。BrewUI 在检测到无法写入时不会贸然去执行 sudo 或者修改文件权限而是提示用户先到终端运行brew doctor看具体原因。这一步非常关键因为 GUI App 如果直接通过do shell script ... with administrator privileges提权执行安装很可能会把/usr/local下一堆目录的 owner 改乱后续更麻烦。我一直觉得GUI 工具应该做的是“引导用户做正确的事”而不是“帮用户执行危险操作”BrewUI 在这点上处理得比较稳妥。系统兼容性方面BrewUI 要求 macOS 13 以上因为大量使用 SwiftUI 新特性。较早的 macOS 版本 Homebrew 本身也还有很多兼容问题所以这个门槛是合理的。我在构建时发现 Xcode 版本也不能太低否则 Swift Concurrency 相关的语法会报错建议至少 Xcode 15。3. 实操过程与核心环节实现3.1 环境准备和源码编译BrewUI 目前没有像 Homebrew 那样一条命令直接安装的公式最靠谱的方式是从源码编译。先确保机器上已经装好 Homebrew如果还没装可以在终端执行官方安装命令这一步是必须的因为 BrewUI 本身不帮忙安装 brew它只是一个前端。然后从 GitHub 上克隆 BrewUI 仓库git clone https://github.com/你的仓库地址/BrewUI.git cd BrewUI open BrewUI.xcodeproj打开 Xcode 后选择你的本地签名团队因为 macOS 默认对未签名的应用有限制签名至少能让你在本地跑起来。然后按Cmd R编译运行第一次编译会比较慢因为要拉取 Swift Package 依赖。如果你在编译时遇到Dependency could not be resolved之类的错误大概率是网络原因多试几次或者检查代理设置就好。如果不想从源码编译也可以去 Release 页面下载打包好的 dmg第一次打开时如果提示已损坏或者无法验证开发者需要到系统设置里手动允许。我个人其实更推荐源码方式因为可以看到日志和底层调用出问题更好排查。3.2 第一次启动检测 Homebrew 位置BrewUI 启动后第一步会探测 brew 可执行文件的位置。它的检测顺序大概是先看/opt/homebrew/bin/brew是否存在再看/usr/local/bin/brew如果都没有会让用户手动选择 brew 所在路径。这个检测逻辑看起来简单但考虑得很细。因为如果你是 Apple Silicon Mac但系统里可能有 Rosetta 环境下的 Homebrew路径是/usr/local/bin/brew也能运行但操作的实际上是 x86_64 版本的包。BrewUI 会优先使用/opt/homebrew/bin/brew只有在找不到时才接受/usr/local/bin/brew。我第一次就在这点了确认因为我的 Intel 老 Mac 只有/usr/local它也能正常识别。检测完成后BrewUI 会显示 brew 的版本号然后自动加载当前已安装的包列表。这一步调用的是brew list --versions加brew outdated因为要拿到“当前版本”和“可更新版本”两个信息。加载期间界面上会有一个转圈动画包很多的时候可能要几秒这是正常现象不是卡死。3.3 常用操作全流程实录我带一个全新用户把 BrewUI 走一遍基本是这样。先在顶部搜索框输入git结果列表里立刻出现git以及相关扩展。点击包名进入详情页能看到版本、描述、依赖、开源许可这些信息。如果已经安装右侧按钮是“卸载”和“固定版本”如果没装则是一个“安装”按钮。点击安装后底部会出现一个任务卡片显示当前的安装进度。这里它不是终端那种滚动 log而是把几个关键阶段列出来下载 tarball、验证校验和、安装依赖、执行 postinstall。每一行前面有绿色对勾或红色叉号。这个体验比终端友好很多尤其是安装大型软件时你一眼就知道现在卡在哪个环节。更新操作也很直观左侧“可更新”分类会列出所有 outdated 包旁边有一个“全部更新”按钮。点击后BrewUI 会逐个执行brew upgrade而不是同时开多个窗口。你可以看到每个包更新的耗时这个数据有时候会暴露一些性能问题比如某个包依赖特别多升级完一大串依赖时间自然长。清理操作我特别想提醒大家BrewUI 的“清理旧版本”默认会先做一次brew cleanup --dry-run也就是只看哪些文件可以被清理但不会真的删。点击后才会执行真正的brew cleanup --pruneall。千万不要看到清理功能就直接点先看清楚列出的旧版本是不是真的不需要了尤其是一些需要回滚的场景。3.4 Brewfile 的导入导出换机必备Homebrew 的 Brewfile 机制可以说是它的杀手锏BrewUI 把这功能做得非常顺手。你可以在 BrewUI 里一键导出当前所有用 Homebrew 安装的包和 cask生成一个 Brewfile 文件。这个文件内容类似这样tap homebrew/cask brew git brew python3.12 cask google-chrome导出后换新电脑时只要在新机器上安装好 Homebrew再在终端执行brew bundle install --fileBrewfile就能把之前的环境完整恢复。BrewUI 也支持导入 Brewfile它会解析文件里的内容自动列出需要安装的包然后让你确认后批量安装。我实际用过几次这个功能比一个包一个包手动装省了太多时间。给我自己的话我会在整理完环境后定期导出 Brewfile 并放到 iCloud 备份这样即使系统挂了或者换机器也能快速恢复。4. 常见问题与排查技巧实录4.1 brew 命令找不到或者检测失败BrewUI 偶尔会报告“Homebrew 未找到”即使终端明明能执行brew。原因就是前面提到的GUI App 启动时不会加载你的 shell profile环境变量里没有/opt/homebrew/bin或/usr/local/bin。所以brew短命令在 GUI 环境下不一定可用。排查方法分三步。第一步在终端执行which brew确认你允许 brew 的完整路径。第二步检查这个路径在 Finder 中是否存在注意大小写。第三步在 BrewUI 设置里手动指定这个绝对路径。大多数情况第三步就能解决因为 BrewUI 一旦拿到绝对路径就不再依赖 PATH 环境变量。如果是 Apple Silicon Mac 但是用 Intel Homebrew也可能会出现异常。这种情况我建议直接重装原生的arm64 Homebrew免得安装的包架构混乱。4.2 安装卡住日志停在 Downoading国内或者网络波动大的时候BrewUI 安装经常卡在下载阶段。原因通常是 Homebrew 默认的下载源速度慢或者某些包从 GitHub Releases 下载超时。这时候要先看日志面板确认是 tarball 下载超时还是实际仍在慢慢下载。如果只是慢可以直接等如果一直 0%就要检查网络。BrewUI 的执行环境里设置了HOMEBREW_NO_AUTO_UPDATE1所以它不是卡在用 update而是卡在真实下载。一个很实用的办法是在终端里手动设置 Homebrew 的下载重试次数和超时时间例如HOMEBREW_HTTP_TIMEOUT300然后从 BrewUI 里重新安装。这个环境变量能否在 GUI 进程里生效取决于你在启动应用时的环境不过一般建议固定把常用环境变量写到~/.zshrc同时也在 BrewUI 的配置里支持自定义环境变量。如果长期网络有问题也可以考虑使用镜像源但这不是 BrewUI 本身能解决的需要在终端层面配置。改完镜像后记得在 BrewUI 里重新执行一次brew update让本地仓库指向新源。4.3 “cannot write to /usr/local/Homebrew” 权限问题这个问题主要出现在 Intel Mac 的老安装方式上。如果你发现 BrewUI 安装任何包都失败并且日志里提到Permission denied大概率是/usr/local下的文件属主不对当前用户没有写权限。正确的排查方法是在终端运行brew doctor它会输出具体哪些目录是 root 所有。然后根据需要修复sudo chown -R $(whoami) /usr/local/Homebrew /usr/local/Cellar /usr/local/Caskroom /usr/local/opt /usr/local/bin /usr/local/etc /usr/local/share /usr/local/var注意这条命令要谨慎只对 Homebrew 相关目录执行不要对整个/usr/local执行否则可能影响其他按装到 /usr/local 的工具。执行完后回到 BrewUI 重新安装大概率能过。如果还是失败可能是一些缓存文件的权限问题可以用sudo chown -R $(whoami) $(brew --prefix)/*一次性修复但这个操作更激进慎重使用。4.4 日志位置和反馈 bugBrewUI 把每次命令运行的原始输出都保存在~/Library/Logs/BrewUI/目录下按日期和时间命名文件夹。当界面日志被折叠或者没来得及看时可以直接去这个目录打开.log文件完整的 stdout 和 stderr 都在里面。排查 bug 时这些日志很重要。如果涉及某个包安装失败还可以去~/Library/Logs/Homebrew/目录下查看 Homebrew 自己写的日志这两个地方配合起来能定位大部分问题。提 issue 时把日志文件和 BrewUI 版本信息一起贴出来维护者回复的速度会快很多。4.5 和终端并行执行导致锁冲突我在用 BrewUI 时有个习惯喜欢在终端开一个窗口随时敲命令有时忘了关 BrewUI 的任务就在终端跑了brew install结果 BrewUI 的任务立刻报Another active Homebrew process is already in progress。这是因为 Homebrew 自身用 lock 文件防止并发。BrewUI 内部虽然是串行执行的但它无法阻止终端用户手动执行 brew。解决方法是要么在终端操作前先暂停 BrewUI 的任务要么干脆养成习惯同一时间只在一个地方管理 brew。BrewUI 在任务失败后的提示里会建议等待一会儿再重试因为另一个进程可能很快就结束。如果一直提示锁冲突可以补充执行brew cleanup再试一次。5. 从 BrewUI 延伸出去的玩法与思考5.1 不只是 formulaCask 和 Tap 也能管理很多用 Homebrew 的人只知道brew install不知道还分 formula 和 cask。BrewUI 在界面里把这两个概念做了明确区分命令行工具类的是 formula比如 git、wget、python带图形界面的是 cask比如 Chrome、VS Code、微信。这样分类对新手来说是极大的帮助我在用终端时经常要犹豫brew install --cask和brew install哪个对现在看一眼分类就明白。BrewUI 也支持管理 tap通过界面可以查看当前添加了哪些 tap 源比如homebrew/cask、homebrew/core也可以手动添加一些第三方的 tap。这个功能在终端里就一行命令但图形化之后可以直观看到每个 tap 对应的仓库和更新状态。5.2 服务管理和依赖树可视化Homebrew 除了装软件还能管理一些后台服务比如你安装的 PostgreSQL 或者 Nginx可以用brew services start启动。BrewUI 把这些服务也列了出来并提供了启动、停止、重启按钮对于不懂命令行的朋友来说非常友好。依赖树可视化是我觉得 BrewUI 最有特色的功能之一。点开一个包的详情页能看到它依赖了哪些其他包以及哪些包反过来依赖它。这种依赖关系在终端里只能用brew deps --tree看文本树但 BrewUI 直接给画成了图形。我在卸载某个包之前一定会看一下反向依赖避免卸载掉其他软件正在用的底层库。5.3 后续还能怎么扩展BrewUI 现在其实还属于早期项目功能上也有一些我想见到的方向。比如支持批量选择多个包一次性卸载支持比较两个时点的包列表差异支持更直观地展示每个包在磁盘上占用空间。还有一个很实用的场景就是和 Homebrew 的brew bundle结合得更紧密生成 Brewfile 时可以选择排除某些包。如果你自己是用 SwiftUI 写 macOS 工具的开发者这个项目的思路很值得借鉴不要重新发明轮子在已有 CLI 工具之上做一层人性化包装只要你能把命令流程编排好、错误输出解析得准确就能做成一个很有价值的小工具。BrewUI 的代码结构不复杂花一个周末读一遍基本就能理解如何在 App 里安全地调用外部进程。我自己实际用了半个月之后最大的一个体会是BrewUI 并没有让我彻底抛弃终端但它确实改变了我和 Homebrew 的日常交互方式。现在很多只想要结果的场景比如“搜一下有没有这个包”“看看哪个包该更新了”我都会打开 BrewUI 而不是敲命令。遇到报错时我也会先从日志面板快速定位再回到终端分析解决。工具是死的思路是活的BrewUI 这种“给命令行打好辅助”的做法至少让我身边不少人愿意开始使用 Homebrew 了。如果你也受够了每次装软件都要复制粘贴命令不妨找个周末把它源码编译跑一下大概率会和我一样用上就回不去了。