装过几十个 Homebrew 包之后，我越来越不想打开终端去做那些重复的brew update、brew outdated、brew upgrade操作。明明只是想看一眼哪个软件有新版本，却要先敲一串命令，再在一堆紫色高亮的字符里找关键信息。后来我换上了 BrewUI，这个用图形界面接管 Homebrew 管理工作的工具，彻底改变了我维护这台 Mac 的方式。
BrewUI 不是一个“用来替代 Homebrew 的东西”，它是 Homebrew 的可视化管理驾驶舱。底层仍然是 Formula、Cask、Tap、Dependency 这些概念，但所有的操作从“记住命令 + 阅读输出”变成了“看列表 + 点按钮”。如果你也和我一样，机器上装着几十上百个包，或者你身边有刚接触 macOS 开发环境、一看到终端就头大的朋友，我强烈建议你了解一下这个项目。
这篇内容不是我对着官方文档念参数，而是我把 BrewUI 作为日常主力工具用了几个月之后，沉淀下来的完整使用经验：从安装到核心功能，从依赖冲突到服务管理，再到哪些场景真的没必要用它。文章偏长，但每一步都是实际操作过的，你可以直接照着来。
1. 受够了命令行？先聊聊为什么需要 BrewUI
1.1 macOS 包管理的前世与命令行的真实痛点
要弄懂 BrewUI 解决了什么，得先明白 Homebrew 本身是怎么回事。Homebrew 是 macOS 上最主流的包管理器，它用统一的命令来安装、卸载、更新那些开源软件和命令行工具。你装 Node.js、Git、FFmpeg、Python 这类东西，大多数时候都会先想到brew install。
但问题出在“管理”这两个字上。安装一个新包很简单，麻烦的是后续的维护：你装了 80 个包，其中有 20 个有依赖关系，每次brew update之后都会有新的版本冒出来，你需要在终端里盯着输出，分辨哪些是你要升级的、哪些是依赖自动升的、哪些升完可能会破坏别的包。还有更琐碎的：磁盘空间不够了想清理旧版本，brew cleanup会告诉你节省了多少空间；想改一个软件源，你得去编辑环境变量；想给 MySQL 做开机启动，brew services start mysql这串命令你得记得住。
这些操作本身不复杂，但频率一高，就变成了一种持续的精神占用。尤其当我同时用好几个开发环境的时候，哪个环境用的什么版本、谁是谁的依赖，在终端里看brew list --tree的输出，虽然够用，但可读性真的很差。
1.2 BrewUI 到底把什么变成了“看得见”的东西
BrewUI 的核心思路很简单：把 Homebrew 的数据库、配置、状态全部用图形界面呈现出来。它读取的不是抽象的中间输出，而是 Homebrew 的原始数据，然后把它们整理成可以被扫一眼就理解的界面。
我的体感是它带来了三个维度的变化。第一，状态可视化。所有已安装的包、有新版本的包、过时的包、存在依赖问题的包，一眼就能分辨，不用在终端输出里慢慢找。第二，操作可逆化。界面上做的每一个动作，其实底层还是在调用 brew 命令，但它会给你确认的机会，而且日志输出比纯终端更直观。第三，管理变成了“浏览”，而不是“记住命令”。你不需要去记brew cleanup --dry-run还是brew cleanup -n，界面上就是一个“清理”按钮，点击之前它会告诉你准备做什么。
1.3 谁适合用，谁其实没必要用
先泼一盆冷水：BrewUI 不是所有人必备的工具。如果你只装了五六个包，一个月只 update 一次，那继续用命令行没问题，别给自己增加一个需要维护的软件。BrewUI 更适合下面这几类人：
- 电脑上装了 30 个以上 Homebrew 包或 Cask 应用，已经记不住自己装了些什么；
- 需要频繁管理依赖关系，比如做 iOS/Android 开发、Flutter 开发、多版本语言环境切换；
- 运营或产品同事偶尔要用 Homebrew 装个工具，但对终端不熟；
- 对那些“把机器搞得一团糟”的场景有焦虑，希望能预览操作后果再执行。
我自己属于第一类和第二类的混合体，这台开发机的brew list输出超过 80 行。在这种数量级下，BrewUI 带来的效率提升是非常明显的。
2. 安装 BrewUI 前后的环境准备与首次运行
2.1 前置依赖：别跳过的 Homebrew 本体
BrewUI 只是一个“壳”，它依赖具备完整功能的 Homebrew。所以在安装 BrewUI 之前，请先确保设备上已经装好 Homebrew，并且执行过至少一次brew update，让本地数据库处于正常状态。
这里要提醒一个很常见的误区：很多人以为 BrewUI 内置了 Homebrew，或者装完 BrewUI 就不用管 Homebrew 了。不是这样的。BrewUI 每次做操作，本质上都是在该用户权限下调用 brew 二进制执行任务，只是把输出和交互包装成了图形界面。
你可以打开终端输入：
brew --version如果能正常输出版本号，并且类似于Homebrew 4.x.x，就没有问题。如果提示 command not found，请先安装 Homebrew：
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"这里再补一条：请确认你的机器架构。Apple Silicon 设备上 Homebrew 的默认前缀是/opt/homebrew，Intel 设备是/usr/local。BrewUI 首次启动时会自动探测前缀，但如果你之前手动设置过HOMEBREW_PREFIX或者有多个 Homebrew 安装目录，就得在 BrewUI 的配置里把路径指对。
2.2 下载与安装的几种方式
BrewUI 本身不是通过brew install brewui装的（至少我写这篇内容时还没有正式的 Formula），主流的安装方式是去项目的 GitHub Releases 页面下载编译好的 dmg 或 zip，解压后拖进 Applications 目录。也有一些用户选择从源码构建：
git clone https://github.com/你的仓库地址/BrewUI.git cd BrewUI swift build -c release源码构建的好处是能第一时间体验新功能，坏处是你得准备好 Xcode Command Line Tools，而且每次都要自己拉代码编译。如果你只是想拿来管理软件包，直接下载发布版就行。
下载完拖进 Applications 后，第一次打开 macOS 可能还会弹“已阻止”之类的提示。这是 Gatekeeper 在拦未经公证的第三方应用。遇到这种情况，不用急着关掉 SIP 或者乱敲 sudo 命令，最简单的方式是在 Finder 里右键点击应用图标，选择“打开”，然后在弹出的确认框里再点一次“打开”。这种处理方式只对当前应用生效，是最安全的绕过手段。
2.3 首次启动的权限问题与目录识别
BrewUI 首次启动会让你选择 Homebrew 前缀，它一般会自动识别出/opt/homebrew或/usr/local中的正确那一个。这个步骤千万别选错，选错会导致后续所有操作都报“找不到 brew”或者“Permission denied”。
紧接着它会请求访问你的 Keychain 或者开发者工具权限。具体取决于版本和运行方式，如果它调用了 git 或 ssh 相关的资源，属于正常现象，因为brew update本身就是一次git fetch。授权的时候注意看弹窗提示，确认是 BrewUI 在发起请求，而不是其他可疑程序。
我的安装过程中遇到过一个额外的问题：第一次启动时它提示“Homebrew 数据库尚未初始化”，但我明明已经装好并正常使用了。后来发现是我的 shell 配置文件里给HOMEBREW_PREFIX设置了自定义路径，而 BrewUI 没有读取我 shell 里的环境变量。解决办法很朴素，在 BrewUI 的设置界面手动填入实际前缀，然后重启应用。这个情况比较少见，但如果你自定义过环境变量，遇到类似报错别慌，先把这个因素排除掉。
3. 核心功能逐项拆解与操作演示
3.1 已安装包列表：从“满满一屏字符”到“一张可检索的表格”
BrewUI 的主界面核心是一个已安装软件包列表。每一行代表一个包，列信息包括包名、版本、安装日期、大小、是否有更新、依赖了哪些包、被哪些包依赖。这些信息在命令行里要靠brew list、brew info、brew deps --tree分段查看，而在 BrewUI 里它们都被整合在了同一个视图里。
我最常用的一个能力是搜索。终端里也有brew list | grep xxx，但 BrewUI 的搜索框是即时过滤的，并且支持按“仅显示有更新”“仅显示 Formula”“仅显示 Cask”“仅显示无条件构建”等维度做筛选。比如我只想看哪些通过 Cask 装的 GUI 应用，只要切换一个标签，比敲brew list --cask舒服得多。
这里顺便解释一下 Formula 和 Cask 的区别：Formula 是命令行软件和库，比如 git、ffmpeg；Cask 是图形界面应用，比如 Google Chrome、Visual Studio Code。BrewUI 会在界面里明确区分这两类，因为它们的管理策略不同。Cask 应用的升级往往需要下载一个完整的安装包，耗时更长，BrewUI 会单独列出它们的升级状态。
3.2 搜索、安装与卸载：按钮背后其实还是 brew 命令
BrewUI 的搜索本质上就是调用brew search的后端数据，在界面上提供了一个输入框和结果列表。你在搜索框里输入node，它会匹配 formula 名称、Cask 名称甚至是描述文字，然后你在结果列表里点了“安装”，它就开始执行brew install node。
别小看这个“点击安装”的动作，BrewUI 做的比裸命令更友好的一点：它在执行安装之前会显示将要执行的完整命令，以及该包的全部依赖列表。比如你装 ffmpeg，它不会直接一路装下去，而是先把依赖树展开给你看，告诉你“这个包会引入 24 个子依赖，总下载量约 XX MB”。装完之后它还提供一个日志面板，记录每一步输出，方便你在出问题时跟踪。
卸载也是同样。选中包，点卸载，它默认会带上--ignore-dependencies的选项确认。为什么不是直接递归删除所有依赖？因为有些依赖是共享的，你卸载这个包并不代表别的包不再需要它。BrewUI 的处理方式是默认只卸载当前选中的包，然后提示你“检测到以下包不再被其他包依赖”，让你决定是否清理。这种“多步确认”在命令行里几乎没办法做得这么直观。
3.3 更新与升级：从小心谨慎到游刃有余
brew update和brew upgrade是有区别的，这个区别在 BrewUI 里被表达得格外清楚。update是更新 Homebrew 自身的仓库记录，把远端最新的 Formula 索引拉下来；upgrade才是根据索引升级你机器上已经安装的包。
在 BrewUI 的“更新”页签里，它会先展示 update 的状态，然后在下方列出一大堆“可升级”的包，每一个都标注了当前版本和目标版本。我可以勾选我真正想升级的那几个点“升级所选”，也可以直接全选执行。这在终端里需要手动写命令组合，而在图形界面上就是一次勾选操作。
有一个我特别喜欢的细节：BrewUI 升级 Cask 应用之前，会先检测该应用当前是否在运行。如果有进程占用，它会弹出提示，问你是强制退出还是要忽略。这一点真的救了我很多次。用命令行的时候，我经常遇到Error: It seems there is already an app at ...，就是因为忘了退出 Google Chrome 或 Docker Desktop，然后操作中止，重新入锅。BrewUI 在升级前就把这个障碍提前告知了。
3.4 清理与维护：磁盘空间回收的艺术
Homebrew 用久了，机器里会积压大量旧版本的 Formula，特别是那些带版本的库，像node@14、python@3.9，一个包可能同时存在两三个版本。brew cleanup能帮你清掉旧版本，但很多人不敢乱跑，怕误删。BrewUI 把清理做成了“预览 + 执行”模式。
在清理界面里，它先扫描所有不再被引用的老版本文件，列出每一项占用的磁盘空间，左下角汇总“清理后可释放 XX MB”。我盯着列表确认，里面确实是那些不会再用的老版本，再点执行。它内部调用的是brew cleanup -s（这里的-s代表 scrub，还会清缓存），结果输出也非常清晰。
还有一个藏在维护里的实用功能：它可以一键重写 Homebrew 的缓存目录~/Library/Caches/Homebrew。这个目录虽然不起眼，但积少成多后体积相当惊人，尤其是那些经常安装大型 Cask 应用的用户。BrewUI 的清理面板会单独列出缓存大小，你可以一键清空，效果立竿见影，我第一次用直接释放了 3 个多 GB。
4. 依赖关系与冲突处理
4.1 依赖树可视化：把 brew deps --tree 变成一张真树
Homebrew 的依赖关系是使用中最大的隐性成本。你装了一个包，它自带八个依赖；你升级其中一个依赖，可能导致另一个包出问题。在命令行里，brew deps --tree输出的是一大段用缩进和符号拼出来的树状文本，能看懂，但不好看。
BrewUI 把依赖树做成了真正的图形化界面。在任何一个包里展开“依赖”标签页，你会看到它下面挂着一整棵依赖树，父节点和子节点通过连线连接，点击任意子节点可以继续往下钻取。更关键的是它支持“反向依赖”视图：选中一个包，可以看到“谁在依赖我”。这个功能在排查爆炸性升级时价值极高。
举个例子，有次我想把 OpenSSL 升级到最新 3.x，但不确定影响面。在 BrewUI 里搜索 OpenSSL，切到反向依赖页，只见底下密密麻麻挂着二十几个包，从 Python 到 Postgres，全部依赖旧版 OpenSSL。看到这个结果我说什么都没去动它，因为那样的升级牵扯实在太广了。过去我在终端里只能靠brew uses openssl，虽然也能查出反向依赖，但不会有如此直观的视觉冲击。
4.2 常见冲突场景与界面上的解决方案
依赖冲突是 Homebrew 使用中最让人头皮发麻的问题。最常见的冲突形态是同一软件存在两个版本，比如你同时装了python@3.9和python@3.11，某些包的编译会因为你 PATH 里的版本不对而报错。
BrewUI 有一套“冲突检测”机制：在包详情里，它会对比当前已安装的其他包，标出它们之间是否存在版本竞争或者文件覆盖风险。比如你安装postgresql@15的时候，它会提示你当前已存在postgresql@14，并且二者的二进制路径会有重叠或替代关系，让你选择是共存还是先卸载旧的再继续。
我实际遇到过的比较复杂的冲突是 glibc 和 GCC 版本引起的问题，不是 GUI 应用层面的东西，纯粹是底层编译链。BrewUI 不可能帮你解决所有编译错误，但它能把冲突的源头可视化地展开，告诉你“A 依赖 2.0，B 依赖 1.9，现在你装了 2.0，B 编译不过”。这比我在终端里翻一长串编译日志找哪里版本不匹配要直观得多。
4.3 卸载时“连带卸载”的判断误区
很多用户在界面上看到“卸载前提：以下包不再依赖它”就会直接点清理，认为这就是“安全卸载依赖”。我因为太信任自动判断，踩过一次坑。
情况是这样的：我用 BrewUI 卸载了某个不再需要的旧 Ruby 版本，它提示“检测到有 3 个包不再需要这个 Ruby 的运行时依赖”，我顺手点了全部清理，结果其中一个工具在下次启动时报错，因为那个工具虽然不依赖 Ruby 运行时，但它的一个编译期组件引用了这个路径。BrewUI 的判断依据是 Homebrew 的依赖元数据，它不会去扫描每个二进制文件实际链接的动态库，所以“元数据上不再依赖”不等于“运行时真的用不到”。
从那之后，我给自己定了个规矩：卸载说白了不差那一两分钟的扫描时间，先多点开几个包看看它们的反向依赖，再决定要不要连带清理。BrewUI 支持你在清理前逐项点击查看详情，这个步骤值得花时间。
5. Taps、服务与应用内更新策略
5.1 可视化管理 Tap 仓库
Tap 是 Homebrew 扩展仓库的概念。默认情况下你用brew install走的官方仓库，但很多软件并不在官方源里，需要通过brew tap添加第三方仓库。比如一些数据库驱动、特定公司的内部工具，都藏在各种 tap 仓库里。
BrewUI 里有一个单独的 Tap 管理模块，会列出当前机器上已添加的所有 Tap，每个 Tap 对应一个 GitHub 仓库地址。你可以从这里直接查看该 Tap 里包含了哪些 Formula，也可以勾选删除一个 Tap。删除 Tap 在命令行里是brew untap user/repo，在 BrewUI 里也相当简单——而且它会警告你“此 Tap 当前被 XX 个已安装包引用”，避免你误删仓库导致包信息无法追踪。
我还在这里发现过一个实用的冷知识：你可以很清楚地看到官方 Tap 和自建 Tap 的更新时间。如果你发现某个软件搜不到，很可能是你那个 Tap 很久没有更新了，在 BrewUI 里刷新一下再试，问题迎刃而解。
5.2 Homebrew Services 的图形化开关
Homebrew Services 是管理后台服务、守护进程的一个扩展功能。比如你通过 Homebrew 安装了 MySQL、PostgreSQL、Redis、Nginx，你可以用brew services start/stop/restart来让它们开机自启或者停止运行。
很多用户第一次听到 brew services 时已经被各种参数劝退了。BrewUI 把 services 做成了一个开关列表，界面左边是服务名，右边是状态标签和启动/停止按钮。我可以在同一屏看到所有服务此时此刻的运行状态，点一个钮就能切换开机自启状态。
这个功能的实际意义远大于“图个方便”。举个例子：我本机同时装了 Redis 和 PostgreSQL，用命令行的时候经常忘记某个服务还开着，导致端口冲突或者启动速度变慢。用 BrewUI 之后，每次开机我扫一眼 services 面板，一目了然。更重要的是，它会把服务的日志文件路径标出来，方便你排错时去翻日志。这一切在命令行里要走brew services list、brew services info xxx好几步才能拿到，在 BrewUI 里全部集中呈现。
5.3 应用自身更新的注意事项
BrewUI 也遵循大多数 macOS 应用的习惯，在设置里提供“检查更新”的按钮，或者提示“新版本可用”。但它本身也是伴随 Homebrew 生态发展的，它的更新频率未必和 Homebrew 的更新节奏同步。我的建议是：BrewUI 不需要追新，除非你在某个版本遇到了 bug。
这里说一个具体的版本适配问题。有一段时间我升级了 Homebrew 到新版 4.x，结果 BrewUI 的旧版解析不了 4.x 新格式的 metadata，界面里很多包的状态显示成了“未知”。我没急着卸载 BrewUI，先查了它的更新日志，等作者发布了兼容新版 Homebrew 的版本后升级解决。所以我建议那些长期使用 BrewUI 的用户：当 Homebrew 那边有 major version 升级时，暂缓操作，等 BrewUI 发布兼容更新，然后在 BrewUI 里更新它自己，这是最稳的路径。
6. 实测体验中的性能表现与常见问题
6.1 大数据量下的流畅度与资源占用
我的开发机上安装的包数量在八十个上下，加上依赖，BrewUI 每次启动后加载全部列表差不多需要两三秒。这个速度可以接受，毕竟它不仅要读包的安装信息，还要去解析每个包的 metadata 和依赖关系。
但它有一个值得注意的性能特点：在触发“检查更新”这种操作时，它其实等于后台跑了一个brew update+brew outdated，这个过程在终端里可能需要十秒到几分钟不等，界面上的表现是有一个进度条在转。如果你按了“刷新”然后又去点别的按钮，偶尔会出现“操作排队”的情况，这是正常的，因为底层同一个 brew 命令在同一时刻只能跑一个。我在使用中已经养成了习惯，触发刷新后先看一眼，不着急去点别的东西。
资源占用方面，BrewUI 平时驻留的内存大约在 200 MB 到 400 MB 之间，作为 GUI 应用不算离谱。如果你追求极致的轻量，那它确实不如终端零开销，但它换来的是可读性和操作效率，我认为值得。
6.2 与命令行、脚本的兼容性
BrewUI 会不会和命令行之间产生冲突？这是很多用户担心的问题。从我的使用经验来看，两者是不会互相打架的：BrewUI 只是 Homebrew 的另一个前端，它操作的是同一套数据库、同一个安装目录，所以你用命令行装的包会在 BrewUI 里出现，反之亦然。
但我建议你注意一件事：不要在同一时刻在终端里和 BrewUI 里同时跑两个 brew 操作。因为 Homebrew 自身很忌讳并发写操作，比如你在 BrewUI 里正在brew upgrade，又跑到终端执行brew install，其中一边会报错“Another active Homebrew process is already in progress”。这不怪 BrewUI，是 Homebrew 的全局锁机制。配合使用时，讲究一个先后顺序就不会有任何问题。
我个人的习惯是：日常的查看、浏览、升级选择走 BrewUI，遇到批量、精确参数的安装或复杂的自定义编译配置时，回到命令行操作。两者互为补充，而不是互相排斥。
6.3 遇到问题时的排查顺序
用 BrewUI 这些年，我碰到过几次“界面里看到的和终端里执行的不一样”的情况。整理一套自己的排查顺序，分享给你：
- 先看 BrewUI 的操作日志面板，它每次操作都会留下完整输出，十有八九里面的报错信息能直接指明原因。
- 回到终端手动执行同一条命令，看是否复现。如果终端也报错，那基本就是 Homebrew 本身的问题，而不是 BrewUI。
- 检查 Homebrew 版本和 BrewUI 版本是否匹配，有没有 major version 的失配。
- 清空 BrewUI 的本地缓存目录，重启应用。有时纯粹是界面的状态数据过期了，不是真的出错。
- 如果还不行，去项目的 GitHub Issues 搜关键词，这种工具的用户群体不小，你踩过的坑大概率有人已经问过了。
第 2 步是定位问题最重要的一步。BrewUI 再怎么包装，它执行的就是那些 brew 命令，终端不通过它能直接验证。记住这个原理，绝大多数“BrewUI 怎么不工作了”的问题都能在五分钟内定位到。
7. 我的建议：哪些场景请回到命令行更高效
7.1 编辑器、脚本与自动化场景仍建议用 brew 命令
BrewUI 做得再好，它也是一个交互式图形程序，不适合用在自动化场景。比如你想写个 shell 脚本，在 CI 环境里批量安装依赖，或者通过brew bundle根据 Brewfile 恢复一套完整的环境，这些都应该继续用命令行。
我自己的做法是：brew bundle相关的工作完全留在终端。我用一个 Brewfile 文本记录了所有需要安装的包和 Cask 应用，在重装系统或者换新 Mac 的时候，一句brew bundle就全部装回来了。BrewUI 也支持查看当前包的清单，但它的定位是浏览和操作单个包，而不是批量恢复环境。
还有一类场景也必须留在命令行：你需要精确控制参数的时候。比如brew install带--build-from-source、--HEAD这类特殊选项，BrewUI 的交互模型很难覆盖所有的 edge case。这种精细活儿，命令行是唯一正确的工具。
7.2 混合使用的最佳实践
如果你问我日常份额怎么分配，我的答案是：大约七成用 BrewUI，三成用命令行。BrewUI 管的是“看清楚 + 日常维护”，命令行管的是“自动化 + 精确控制 + 批量操作”。
具体到一天的使用流程里，我一般是这样操作的：
- 早上起来打开电脑，先瞄一眼 BrewUI 的更新页，看看有没有依赖需要升级，心里有个数；
- 需要装一个新的开发工具时，先在 BrewUI 里搜索，查看它的依赖树，确认影响面后再安装；
- 如果我要一口气装一整套环境，比如配一台新电脑时，直接用终端跑
brew bundle； - 排查具体 bug 的时候，终端看日志和依赖关系，BrewUI 做辅助的图形化参考。
这套流程磨合了相当长一段时间才稳定下来。最开始我总是想“既然有 GUI 了，什么都用它点”，后来发现效率反而下降；然后又走向另一个极端，只在 BrewUI 里看看状态，其他全回终端，又觉得没发挥它的价值。现在这个比例，是我用起来最舒服的状态。
最后再分享一个小技巧：如果你经常在 BrewUI 里“清理旧版本”，记得在清理前先看一眼它列出的“此项会释放 XX MB”的汇总数字，连续观察几天，摸清自己机器上的包增长规律。你会发现，很多看起来巨大的“可清理空间”，其实只是一两个大型 Cask 应用的历史安装包，搞清楚来源之后，你会对整台机器的存储占用有更清晰的掌控感，而这一点恰恰是命令行给不了你的。
