尧图精选

BrewUI 使用指南:给 macOS 的 Homebrew 配一个好用的图形界面

🕒 发布时间:2026/9/20 11:34:32 📁 来源:尧图网络
1. 为什么我给 Homebrew 配了一个图形界面用 macOS 开发的同学几乎绕不开 Homebrew 这个包管理器。日常装个 nginx、redis、ffmpeg一条brew install xxx就搞定数据基本都沉淀在/opt/homebrewApple Silicon或者/usr/localIntel目录下终端里敲命令也确实高效。但我身边不少同事、朋友包括一些刚转行做前端、做设计的同学一看到终端就发怵更别提记brew services list、brew autoremove这些不太常用的子命令了。我第一次接触 BrewUI 这个项目就是帮一个朋友排查电脑磁盘占用问题。他电脑里用 Homebrew 装了几十个包很多都是以前试过就再没用过的但他完全不知道该怎么清理也不敢乱删。当时我脑子里第一反应是如果有个可视化的界面能让他看清楚装了些什么、占了多少空间、哪个可以安全卸载问题就简单多了。于是我搜了一下还真找到了 BrewUI 这种专门给 Homebrew 做图形化管理的开源工具。简单说BrewUI 就是给 Homebrew 套了一层图形界面让你不用碰终端也能完成大部分日常的包管理工作。它解决的核心问题是三件事看清——你机器上到底装了哪些包、每个包多大、哪些有更新管好——升级、卸载、清理缓存、管理服务都可以用鼠标完成省心——定期帮你检查更新不用天天手动去敲brew update brew upgrade。这篇内容适合三种人看一是刚用 macOS 不久、对终端不熟的新手想用更直观的方式管理开发环境二是用 Homebrew 很久但嫌命令行麻烦的老手想提升日常维护效率三是在帮亲戚朋友维护电脑时希望有个靠谱、安全、不乱来的图形化工具的人。需要提前说明的是BrewUI 本质上还是调用 Homebrew 底层能力它不是替代品而是对命令行的可视化封装。理解这一点后面很多操作逻辑你就能自己推导了。2. 图形界面管理 Homebrew核心思路其实就一句话我先说说 BrewUI 这类图形化包管理工具背后的设计思路理解了思路你才知道为什么有些功能它有、有些功能它没有以及遇到问题该从哪里下手。2.1 它不是替代 Homebrew而是命令行的“翻译器”Homebrew 本身是一个功能非常强大的命令集合它包含几百个子命令和参数。BrewUI 做的事情说穿了就是把这些命令行的输入输出翻译成图形界面上的按钮和列表。你在 BrewUI 里点一下“升级所有”它后台执行的就是brew upgrade你在界面上勾选某个包并删除它执行的就是brew uninstall 包名。为什么这个设计很重要因为它意味着你完全不用担心 BrewUI 会搞出一套“自己的逻辑”来管理包。你从界面上看到的状态和你在终端里用brew list、brew outdated看到的状态是一致的。万一哪天你不满意 BrewUI 了退回终端操作一切照旧没有任何数据格式上的绑定或迁移成本。2.2 权威数据源来自 brew 本身的元数据BrewUI 能显示每个包的版本、依赖关系、安装日期、大小、有无更新这些数据全部来自 Homebrew 自己维护的元数据。它读取的是/opt/homebrew下的安装信息、/opt/homebrew/var/homebrew/linked里的软链接关系以及 brew 命令执行时输出的 JSON 结构化结果。这里要注意一个关键点Homebrew 从很早就支持brew info --jsonv2这种 JSON 输出格式这意味着第三方工具可以非常稳定地解析出包名、版本、依赖树、安装路径等信息。BrewUI 这类项目之所以能做出漂亮的界面底层靠的就是这个 JSON 接口。我给一个直观类比Homebrew 像一家图书馆的馆藏系统里面每本书都有详细的登记信息BrewUI 像图书馆大厅里的电子查询屏。你不必跑到柜台终端去问管理员命令行因为查询屏后面接的还是那套馆藏数据库数据绝对一致。2.3 设计取舍做“必要的功能”不做“全部的功能”我看过不少人对 BrewUI 一类的工具吐槽说“这个功能没有”、“那个功能不够细”。实际上图形化工具在功能边界上是有意做减法的。为什么因为有些操作极度依赖上下文比如brew install时选择从源码编译还是下载预编译二进制需要在命令行里传--build-from-source比如brew edit修改 formula 文件这种场景天然适合终端。BrewUI 的定位是高频、低风险、适合可视化的操作。它优先做好这几件事包列表一目了然、更新状态一目了然、一键升级安全可靠、卸载清理不会误删。而那些开发调试级别的高级操作它故意不碰。这是聪明的设计因为工具一旦试图覆盖一切界面就会变得无比复杂复杂度反而成了新用户的负担。3. 安装与配置几个必须提前知道的前提和步骤说完了思路进入实战。这一节我会把 BrewUI 的安装过程、前置条件、配置要点完整写出来。你照着做基本不会有坑。3.1 安装前检查两个前提第一你的 macOS 必须已经装了 Homebrew。怎么确认打开终端输入brew --version如果能输出版本号说明已经装好。没装的话先去 Homebrew 官网按官方流程装好再来BrewUI 不会帮你装 Homebrew。第二系统版本建议 macOS 12 或更高。这主要是因为 BrewUI 用到了较新的系统 API 来做界面渲染和系统集成旧版本也能跑但部分界面元素可能显示异常。3.2 两种安装方式下载应用包 vs Homebrew 安装BrewUI 的安装方法有两种我分别说下适用场景。第一种是直接下载编译好的应用程序包.app。这种方式最简单下载后拖入“应用程序”文件夹即可运行。适合不想碰终端的用户。下载时留意选择对应芯片架构的版本Apple Silicon 选 arm64Intel 选 x64。选错的话应用可以启动但解析 Homebrew 路径时会失败因为默认路径不一样。第二种方式是用 Homebrew 安装brew tap brewui/brewui brew install --cask brewui用 cask 方式安装的好处是后续升级方便一条命令搞定。而且 cask 会自动识别处理器架构省得你自己选。我个人推荐有一定终端基础的人用这种方式。无论哪种方式装完第一次启动时BrewUI 可能请求“完全磁盘访问权限”或“辅助功能权限”。这个不是它要偷看你文件而是因为 Homebrew 的某些目录位于系统保护区域程序需要权限才能读取安装列表和清理缓存。你直接在“系统设置—隐私与安全性”里把 BrewUI 加进去就行。我遇到过很多次用户卡在这一步说“怎么界面上什么都看不到”十有八九是权限没给。3.3 首次启动后的配置项BrewUI 首次启动后会在菜单栏多出一个图标点击图标就能展开主面板。进入“设置”页有几个配置项值得你认真调一下自动检查更新频率默认是每天检查一次。我个人建议保持这个频率没必要更频繁因为 Homebrew 的 formula 更新源基本是稳定的一天一次足够。更新后是否自动清理旧版本默认开启。这个功能对应命令行里的brew cleanup作用是把已安装包的老版本残留清理掉。建议开启能节省不少磁盘空间。是否显示“已安装但不依赖”的包这个对应brew leaves。开启后你能在界面上看到那些“顶层包”就是当初你明确安装、现在没有任何其他包依赖它们的东西。这个信息对清理无用包很有用。4. 核心功能逐项拆解每个按钮背后到底执行了什么BrewUI 的主界面通常分几个区域应用列表、更新面板、服务管理、存储分析。我一个个拆开讲重点说清每个功能背后对应的命令行逻辑以及你在点击时需要注意什么。4.1 应用包列表看清你装了什么主界面的应用列表会展示当前 Homebrew 管理的所有已安装包包括 formula命令行工具类和 cask图形应用类。每一行会显示包名、当前版本、是否有更新、安装日期、大小。顶部通常有筛选框你可以按名称搜索也可以按“仅显示需要更新的”“仅显示 cask”“仅显示 formula”来过滤。有一个细节值得注意列表里显示的大小和你在“存储空间”里看到的实际占用可能不一致。原因是 Homebrew 的 formula 包在安装时可能包含构建缓存、依赖缓存这些不会都算在包本身的“大小”字段里。真正占空间的往往是~/Library/Caches/Homebrew这个缓存目录后面我会讲怎么清理。在列表里点击某个包会展开详情页能看到更细的信息依赖了哪些包、被哪些包依赖、安装时用了什么 option、有没有安装服务service等。这些信息对判断“某个包能不能删”很有用。4.2 一键更新升级之前务必要看更新内容更新面板会列出所有有可用升级的包你可以勾选其中一部分升级或者全部升级。它底层执行的是brew upgrade但你可以在设置里选择升级前是否自动执行brew update更新仓库索引。我在实操中强烈建议的一件事是升级前先点开每个包的更新详情看看这次版本变化大不大——主版本号变化比如 2.0 → 3.0往往意味着不兼容的改动某些依赖它的项目可能会挂。你自己本地的项目如果依赖某个包升级前最好看一眼 changelog。另外升级是一个 CPU 和网络开销都比较大的操作尤其碰到需要源码编译的包可能要编译十几分钟。BrewUI 的更新面板会显示当前的进度条我实测下来如果某个包卡在“building from source”阶段进度条长时间不动是正常的耐心等就行别手滑点取消。4.3 卸载与清理安全卸载的核心判断逻辑很多人用 BrewUI 是冲着“清理”来的。这里我必须把逻辑讲清楚否则你可能会误删东西。BrewUI 的卸载功能分两类第一类是卸载单个包。你在列表选中某个包点击“卸载”它会先检查这个包是否被其他已安装包依赖。如果有依赖界面会弹出警告列出依赖它的那些包。这时候你就得想清楚你卸载它可能会导致那些依赖它的包无法正常工作。比如很多包都依赖openssl你把它卸了一堆东西会出问题。第二类是清理“孤儿包”。所谓孤儿包就是当初作为某个包的依赖被自动安装上来但现在那个包已经被卸了或者新版不再依赖它了于是它就成了没人要的孤儿。命令行对应的操作是brew autoremove。在 BrewUI 里这个功能通常在“存储空间分析”或“清理”模块里一键就能跑。这个操作相对安全因为设计逻辑就是“移除所有不再被依赖的包”但我仍然建议在执行后看一眼弹出的清单防止某些你还想留着的工具被清掉。4.4 服务管理一键启动 nginx、redis 这类常驻进程Homebrew 的管理能力里有一个很实用的子模块brew services。它管理的不是普通命令行工具而是常驻后台的服务进程比如 nginx、redis、mysql、postgresql 这类。BrewUI 单独做了一个服务管理面板列出当前所有注册了服务的包显示运行状态启动/停止/未注册并提供“启动”“停止”“重启”“设为开机自启”四个操作。这对不熟命令行的用户来说是巨大的解放——你不需要记住brew services start nginx、brew services stop nginx这种差异极小的命令点按钮就完事。有个小技巧很多时候服务启动失败不是配置问题而是端口被占用。BrewUI 的服务详情里会显示日志路径你点开日志就能看到具体的报错比在终端里翻日志方便太多。4.5 存储分析看看空间都被谁占了存储分析模块是 BrewUI 最有视觉冲击力的功能。它用图表展示每个包占用的磁盘空间、Homebrew 缓存大小、下载临时文件大小。从这里你可以一眼看出“罪魁祸首”是谁。当你点击“清理缓存”它执行的是brew cleanup会删除~/Library/Caches/Homebrew下的旧版本压缩包和安装临时文件。这个操作非常安全因为缓存本来就是可以随时重新下载的。我实测中清理前先看一眼缓存大小有时候能清出几个 GB效果立竿见影。5. 实操记录我用 BrewUI 给一台旧电脑做了一个周末大扫除光讲功能太抽象我把最近一次实操完整记录下来你可以拿这次过程当模板。5.1 实操前的摸底盘查朋友的 MacBook 是一台 2020 款 Intel 机型256GB 硬盘已经用了快三年。他最近频繁收到“磁盘空间不足”的警告想让我帮忙看看。我打开终端查了下 Homebrew 情况brew list --formula | wc -l # 输出47 brew list --cask | wc -l # 输出2347 个命令行工具、23 个图形应用看起来不算特别多但结合 256GB 硬盘来看确实需要清理一下。安装 BrewUI 后我第一时间打开了存储分析模块。结果比我预想的更直接Homebrew 缓存目录占用 2.8GB——这个数字明显偏大因为里面可能积压了好几次升级产生的旧版本缓存。有一个老版本的 Python3.9和它的一堆依赖总计约 900MB而系统里已经装了 3.11 和 3.123.9 早已没有项目在用。有 6 个独立安装过但现在没有任何依赖它们的“顶层包”其中包括他当初好奇装的cowsay和figlet——这两个我确定他再也不会用到。5.2 执行清理的完整流程第一步我先在存储分析里点了“清理缓存”几秒钟后反馈释放了 2.8GB。这一步没有任何风险属于常规操作。第二步处理 Python 3.9。我选中 Python3.9界面弹出依赖警告显示有几个包仍然依赖它。我进一步点进依赖详情发现依赖它的都是 3.9 时代装着玩的小工具绝对可以一起卸。于是我先把这几个小工具卸载再卸 Python3.9全程没有触发任何异常。第三步处理“孤儿包”。我进入清理模块点击“分析孤儿包”界面列出了 11 个包。我逐一确认过都是不认识的、明显是历史遗留的依赖于是勾选全部清理。结束后看日志释放了约 1.7GB。第四步检查服务的运行状态。我看到 nginx 处于“已启动”状态但他说他从来没主动启动过 nginx我怀疑是某次安装某个包时被作为依赖装进来并自动注册了服务。我直接点了“停止”并在设置里把它的“开机自启”关掉省得下次重启又会悄悄跑起来。整个清理过程大约 15 分钟释放的总空间在 6GB 左右对 256GB 硬盘来说算是一笔可观的空间。朋友后续又用了两天反馈系统明显清爽了很多开机后也不会再弹磁盘警告。5.3 这次实操里我踩到的一个小坑清理过程中我犯了一个错误在卸载 Python3.9 之前我没有先检查有没有“当前正在运行”的进程依赖它。卸载执行到一半BrewUI 提示“部分二进制文件正在使用中”操作被中断。原来他开着的一个终端窗口里某个 Python 脚本还在后台跑。解决办法很简单我先在活动监视器里把那个 Python 进程结束掉再重新点卸载一次成功。这说明了一个通用注意事项卸载任何运行时包Python、Node、Ruby 等之前先确认没有相关进程在跑否则轻则卸载失败重则留下半个残留包。6. 常见问题与避坑速查用 BrewUI 这段时间结合我和身边人遇到过的各种问题整理成一张速查表遇到问题先来这里翻一翻。问题现象可能原因解决办法界面空白BrewUI 主列表不显示任何包未授予完全磁盘访问权限在系统设置中给 BrewUI 授予权限后重启应用点击升级没反应进度条一直卡在 0%Homebrew 仓库索引过期在设置里手动触发“更新 Homebrew”或终端执行brew update提示路径不存在界面报“/opt/homebrew 不存在”Intel 芯片机器上 Homebrew 装在 /usr/local在 BrewUI 设置里修改 Homebrew 路径卸载包后被警告“影响其他包”弹窗列出依赖该包的软件这是正常的保护机制仔细核对依赖确认误删风险后再操作服务启动立即退出服务状态显示“已停止”通常是端口被占用或配置文件有误查看服务日志定位到具体报错清理缓存后空间没变多磁盘占用看不到变化缓存清理的是隐藏目录Finder 不显示用系统“存储空间”设置查看或另用磁盘工具确认6.1 两个最容易被忽略的隐藏坑第一个坑是Homebrew 的 formula 和 cask 混装导致的误判。有些包既有 formula 版本又有 cask 版本比如google-chrome你如果用 cask 装过图形版 Chrome同时又用 formula 装过某个命令行相关的 Chrome 工具BrewUI 里可能会显示两个“Chrome 相关”条目但一个属于应用列表、一个属于包列表。清理时如果不小心删了 cask 版本的 Chrome 应用你桌面上的 Chrome 图标就会消失。所以在“卸载”前一定先看清楚类型标识。第二个坑是某些包的安装位置不是标准的 Homebrew 目录。大部分 formula 会装到/opt/homebrew/Cellar下但个别包特别是用自定义--prefix参数安装的会装到其他位置。BrewUI 默认只监听标准目录碰到这种“非标准安装”的包它可能显示不出来。如果你发现某个色包明明装了但 BrewUI 里看不到、磁盘又确实被占用可以到终端里执行brew list --verbose 包名来确认实际路径。6.2 我的使用经验和安全建议用 BrewUI 一段时间后我总结几条安全使用原则第一升级和清理分开做。很多人喜欢一口气“升级 清理缓存 清理旧版本”我建议不要。升级前先看看有哪些包要升级判断变化大小升级后再清理缓存。混在一起操作万一升级中某个包失败清理过程可能会把临时文件删掉反而让排查问题更困难。第二不要频繁执行“清理孤儿包”。brew autoremove类操作本质上是“清除所有不被依赖的包”这个操作过频的话可能会有误伤风险——比如你刚装了一个软件还没来得及用另一个包把它作为依赖装上了然后这个依赖又被判定为“孤儿”给清掉。这不是 BrewUI 的问题是 Homebrew 本身的依赖管理逻辑决定的。我的建议是每次要清理孤儿包前扫一眼列表看到自己认识的、在未来可能用到的就取消勾选。第三重要操作前先看一眼日志。BrewUI 每个操作完成后都会生成日志页面底部有快捷查看入口。养成习惯每次升级或卸载后扫一眼日志看有没有 warning 或者 error。我见过有人在卸载包时看到日志里有“uninstall failed”但界面没弹出明显提示结果包其实只剩一半后患无穷。7. 适合谁用、不适合谁用我的真实评价如果你问我BrewUI 值不值得装我的回答是看你的使用场景和使用习惯。如果你属于这几类人我非常推荐你装一个用 Homebrew 但只使用其中不到十个包的“轻度用户”你的需求就是安装、偶尔升级、偶尔清理图形界面完全够用。帮家人朋友维护电脑的人。你自己熟悉命令行没问题但对方不一定。装上 BrewUI 之后对方自己就能看图点按钮不用每次找你。做开发但更关注业务逻辑、不想为环境管理分心的程序员。BrewUI 把包更新状态可视化以后你只需要每天瞄一眼“有没有过时包”有就点一下升级很省心。但如果你属于以下几类人我建议你保留纯终端方案或者至少不要完全依赖 BrewUI需要频繁调试 formula 源码的开发者。你会经常用到brew edit、brew reinstall --build-from-source这类高级参数图形界面不可能完全覆盖。对 Homebrew 内部结构已经非常熟悉、且形成自己一套高效命令行流程的老手。对你来说图形界面反而可能拖慢操作速度。维护的机器数量很多需要脚本化批量操作的人。BrewUI 没有也不应该做批量部署功能脚本化还是得靠 terminal。说到底工具的价值在于匹配场景不在于“功能多”。我现在的使用习惯是命令行和 BrewUI 并行。日常维护、给新手演示、快速看状态用 BrewUI真正需要精细控制和批量处理时切回终端。两条路都保留整个环境管理就非常从容。如果你也打算尝试我从实际体验出发的建议是先抱着“这只是一个 Homebrew 的可视化客户端”的心态装一个花十分钟把每个按钮都点一遍对照本文讲的命令行逻辑去理解。你会发现命令行里那些看似晦涩的操作在图形界面里其实非常直观而理解了背后的本质之后你反而会更愿意去敲那些命令行语句。BrewUI 这类项目让我感触最深的一点是优秀的工具不是替你做决定而是把做决定所需的信息以最低成本呈现给你。它不会替你判断“哪个包该删”但它让你一眼看懂“这个包占了多大空间、还有没有人依赖它”——当信息透明了决策自然就简单了。希望这篇分享对你有帮助。
上一篇/下一篇内容由系统自动关联 返回资讯列表 →