Mac 上跑开发的，大概没有人能绕过 Homebrew。我从 Intel 时代一直用到 Apple Silicon，brew install敲了上万次肯定是有的。但用着用着我就发现一个尴尬的事：命令行管理软件包，爽是爽，就是缺一个“全局视角”。装了什么、哪个能更新、谁依赖谁、那些缓存占了几个 G，这些信息在终端里得靠好几条命令东拼西凑。后来我换了个思路，给 Homebrew 配了一个图形界面客户端 BrewUI，前后用了两个多月，整体体验比我想象中稳定得多。这篇文章不写软文，就把我怎么装、怎么用、中间踩了哪些坑，一条一条整理出来，给同样在折腾 Homebrew 的朋友做个参考。
BrewUI 说白了就是一个基于 Homebrew 命令行的桌面包装器。它不替代brew，也不会发明一套新的包管理逻辑，而是把 Homebrew 已经存在的数据和操作，用窗口、列表、图表的方式重新呈现给你。对新手来说，它让你不用记brew search、brew info、brew list这些命令就能完成大多数日常操作；对老手来说，它把brew outdated、brew deps --tree、brew cleanup --dry-run这类查询结果直接画成界面，省掉你自己拼管道的功夫。这篇分享适合所有用 macOS 做开发或日常办公的人，尤其是那些觉得“Homebrew 好用但命令太多”的朋友。
1. 为什么命令行明明很顺手，我还要装一个图形界面
1.1 终端里最难回答的三个问题
我常用的 Homebrew 命令其实屈指可数：install、uninstall、update、upgrade、list、cleanup。熟练之后确实很快，但如果你负责的是一台用了两三年的主力开发机，就会发现命令行在回答下面三个问题的时候特别费劲。
第一个问题是“我到底装了什么”。brew list能列出所有 formula，但输出就是纯文本流，几百个包在终端里刷过去，你根本没法一眼看出哪些是核心工具、哪些是某个大软件带进来的附属依赖。第二个问题是“这个包是谁引进来的”。项目装多了之后，很多包不是你主动装的，而是被当作依赖拖进来的。想卸载某个包又不敢删，就怕系统里还有别的东西指着它。brew deps --tree能画依赖树，但几十上百个节点的树形输出，在终端里看起来就是一大坨变形的括号和竖线。第三个问题更实际：“磁盘空间到底被谁吃了”。Homebrew 的缓存、旧版本、日志散落在好几个目录里，单个文件都不大，合起来却能轻松超过 5 个 G。我有一次帮朋友清理一台 Mac，光~/Library/Caches/Homebrew下面的下载缓存就占了 6.8 G，他之前完全没意识到。
这三个问题，用命令加管道再加各种参数其实都能拼出来，但每次都要重新拼，实在不划算。尤其是当你只是想快速确认一件事的时候，等命令输出的那几秒钟都显得漫长。我理想中的工具，是能把包名、版本、依赖、更新状态这些数据变成一张张能看、能点、能筛选的界面，这正是 BrewUI 的定位。
1.2 BrewUI 是怎么做到“所见即所得”的
BrewUI 界面上的信息不是自己猜出来的，它直接调用 Homebrew 的底层接口拿到原始数据，再渲染成界面。首页的“已安装”列表，本质上就是brew list --formula和brew list --cask两个命令的合并结果；每个包旁边的“有新版本”标记，对应的是brew outdated；点进某个包的详情页看到的依赖关系，数据源来自brew info。所以它的展示是准确的，不会出现界面说某个包存在、但终端里却查不到的情况。
这种设计还有一个很实际的好处：它不会和 Homebrew 的发展脱节。只要brew命令本身的行为不发生破坏性改变，BrewUI 就不用频繁跟着改版。反过来，你也别指望 BrewUI 能做什么超出 Homebrew 能力范围的事。它更像一个“整理好的遥控器”，电视还是那台电视，遥控器只是把常用按钮摆得清楚了一点。
真正用下来，我感受最深的不是“能装的软件变多了”，而是“对这台电脑上的软件心里终于有数了”。以前我只能凭记忆猜测系统里有哪些包，现在打开 BrewUI 一屏全看得见，哪种踏实感，是命令行给不了的。下面这张表是我自己总结的 CLI 和 GUI 的日常操作对照：
| 操作场景 | 终端命令 | BrewUI 操作 |
|---|---|---|
| 查看已安装包 | brew list | 左侧“已安装”列表 |
| 搜索软件 | brew search 关键字 | 顶部搜索框模糊搜索 |
| 查看可更新包 | brew outdated | “可更新”页红色标记 |
| 查看依赖关系 | brew deps --tree | 包详情页依赖图 |
| 清理缓存 | brew cleanup --prune=all | “存储空间”页一键清理 |
| 固定版本不升级 | brew pin 包名 | 包右键菜单“固定版本” |
2. BrewUI 的安装与首次初始化
2.1 三分钟装好 BrewUI，三种方式随你选
先说前提：BrewUI 是 Homebrew 的客户端，所以电脑上必须先装好 Homebrew 本身，还没装的话先去官网复制安装命令，一条命令搞定。接下来装 BrewUI 最省事的路径，是直接用 Homebrew 自己的 cask 通道：
brew install --cask brewui执行完这条命令，系统会自动下载 BrewUI.app 并安装到“应用程序”目录，桌面和启动台里就能直接打开。
如果你的网络访问默认仓库比较慢，走上一条路可能会卡在下载阶段。这时候可以走第二条路径：去项目的 GitHub Releases 页面下载最新的.dmg或.zip包，手动把 BrewUI.app 拖进“应用程序”文件夹。这种方式不依赖 Homebrew，适合想先试试、暂时不想动系统环境的人。
还有第三条路径，适合喜欢折腾源码的：把仓库 clone 下来用 Xcode 跑。BrewUI 用的是 SwiftUI 框架，代码量不算大，打开BrewUI.xcodeproj直接 Run，就能以开发模式启动。我自己第一次看这项目源码，是想确认一件事：它到底会不会在后台偷偷执行什么不该执行的命令。看完源码确认了，它所有弹窗提示的执行动作，都是走/usr/local/bin/brew或/opt/homebrew/bin/brew这个系统路径，没有藏着掖着的旁门左道。
注意：Apple Silicon 和 Intel Mac 的 Homebrew 安装路径不一样，前者是
/opt/homebrew，后者是/usr/local。BrewUI 首次启动时会自动探测 brew 可执行文件的位置，一般不需要手动配置。如果你是用源码方式跑，务必确保本机已经装好 Xcode 和 Command Line Tools。
2.2 首次启动时，它在后台偷偷做了三件事
第一次打开 BrewUI，界面会有一个短暂的“正在初始化”状态，那个转圈的动作一般持续几十秒。这段时间里它其实在干三件事：定位 brew 可执行文件、读取当前已安装的所有 formula 和 cask、对比远端仓库检查可更新版本。首次扫描的耗时取决于你装的包数量，装了几百个包的话可能要一分多钟，但只要不是卡住不动，耐心等就行。
扫描完成以后，主界面分成几个区域：左侧是导航栏，有“已安装”“可更新”“所有软件”“存储空间”等入口；中间是包列表，每个包一行，显示名称、当前版本、是否有新版本、分类标签等信息；右上角是刷新按钮和设置入口。整体布局和 macOS 自带的软件管理界面风格接近，学习成本非常低。
这里我要多说一句：首次启动完成后，最好立刻点一下“检查可更新版本”，让 BrewUI 把远端状态拉全。因为默认情况下，它为了不拖慢启动速度，不会在打开应用的一瞬间就请求网络。等那十几秒跑完，所有包旁边的“有新版本”小红标才会齐全，否则你会以为系统里所有软件都是最新的。
3. 核心功能逐个拆解，看完就会用
3.1 管理已安装软件：筛选、搜索、定位的组合玩法
BrewUI 的“已安装”页面是我日常打开最频繁的页面。它能按 formula 和 cask 分类过滤，也支持直接搜索包名。这个搜索不是简单的前缀匹配，而是模糊搜索，比如输入python，会把python@3.10、python@3.12、python-tk@3.12这些相关条目一起列出来。对我来说，这直接解决了一个痛点：不用记住某个包完整且准确的名称了，打个大概就能找到。
每个包后面的下拉动作菜单里，藏着一个被我称为“找文件神器”的选项：在 Finder 中显示。点一下，它会直接打开该包在 Homebrew 目录里的实际安装位置。以前我想找某个命令行工具的配置文件，都得先which 工具名，再一层层跳目录；现在直接从这个菜单进去，省掉的步骤不是一点点。
还有一个细节值得提：BrewUI 会区分“由你主动安装”和“作为依赖自动安装”两类包，这个信息来自 Homebrew 自身的行为记录。知道这个区分非常重要，因为前者是你可以放心卸载的，后者一定要谨慎，除非你明确知道系统里没有其他包需要它。用 BrewUI 的时候，这个区分会在列表里用不同标签显示出来，一眼就能看出来。
3.2 安装和卸载：小心那个“卸载依赖”按钮
在 BrewUI 里安装一个新包，流程就是搜索、点安装、确认。它会自动处理好所有依赖，然后把安装过程输出到日志面板，你能实时看到它正在下载什么、解压到哪个目录、是否完成了安装。对于新手来说，日志面板最大的作用是“安心”——看着进度在动，就不会像在终端里那样动不动怀疑是不是卡住了。
卸载功能才是 BrewUI 体现价值的地方。在终端里，brew uninstall默认不处理依赖；而 BrewUI 卸载某个包时，会弹出一个窗口问你要不要顺带卸载“不再被使用的依赖”。这个设计很贴心，但我要强烈提醒一句：第一次用的时候，这个勾选项一定要谨慎勾选。
原因在于，“不再被使用”这个判断只认 Homebrew 依赖关系记录，不认你系统里可能存在的其他使用方式。举个我自己的例子：我卸载了一个构建工具，BrewUI 提示它的某个依赖库已经不被任何包引用了，我顺手勾了确定。结果两周后跑一个老项目，编译直接报找不到那个库的头文件。原来是那个老项目的构建脚本手动引用了这个库，而 Homebrew 根本不知道这种引用关系。所以我的经验是：卸载主包时先不勾依赖清理，用几天确认没问题，再回到清理入口做一次依赖回收。多一步操作，少一堆“卸载完某软件后发现另一个软件坏了”的悲剧。
3.3 升级策略：别被“全部更新”带进坑
brew upgrade在终端里是一条非常心大的命令，它默认会把列出的所有包都升到最新版。BrewUI 的“可更新”页面同样提供了一个“全部更新”按钮，但我建议你把它当成一个需要再想想的选项，而不是默认动作。
原因在于，macOS 上不少 formula 是带版本约束的。比如你的项目依赖postgresql@14，但最新版已经到 17，无脑升级会把本地数据库带到一个新的大版本上，紧接着就是数据目录格式变更，如果你没提前做迁移，项目可能直接连不上库。这类问题在命令行时代坑过不少人，到了 GUI 时代依然存在，只是按钮从一行命令变成了一个更大的按钮，误触的代价反而更高了。
BrewUI 的“可更新”页面会列出每个包的新旧版本号，我通常的策略是：先在这个页面里分辨哪些是小版本修复、哪些是大版本跳跃，只勾选前者单独升级。它还支持对某个包右键“固定版本”，效果等同于brew pin，被固定的包会在后续升级操作里自动跳过。我第一次用的时候就把几个数据库相关的大包全部固定了版本，后来偶尔手滑点到“全部更新”，也不会伤到关键服务。这个功能是我认为 BrewUI 做得最贴近真实用户需求的设计之一。
3.4 清理与维护：找回磁盘空间的日常操作
Homebrew 用久了，磁盘空间主要被三类东西吃掉：下载的压缩包缓存、旧版本的安装文件、不再被任何包引用的孤立依赖。BrewUI 在“存储空间”页面把这三类占用分门别类显示成不同色块，每一项都标注了具体占用多少 MB，我每次看到那个页面都会感慨一句：原来这里藏着这么多东西。
这个页面上的核心操作有两个：清理缓存和清理旧版本。执行之前，BrewUI 会先算出一个“预计可释放空间”的数字，让你知道这波清理大概能拿回多少空间。我个人很吃这一套设计，因为它把操作收益前置了，用户看到明确收益才更愿意点下去，而不是面对一个冷冰冰的“确认清理”弹窗。
另外，这个页面还有一个细节：它在计算空间的时候，不会去扫描用户目录下的其他文件，只统计 Homebrew 自己的目录范围。所以如果你觉得磁盘空间还是不够用，那问题大概率出在~/Library/Application Support或者~/Downloads，该去别处找找，这不属于 BrewUI 的管辖范围。
4. 使用 BrewUI 时最常见的几个坑
4.1 权限报错？先别急着改权限
我第一次在 BrewUI 里执行升级时，日志面板直接报了一行Error: Permission denied @ apply2files。我第一反应是权限坏了，打算去改chown，但后来仔细排查发现，真正的原因是这台机器从旧系统迁移后，/opt/homebrew目录下有一小部分文件的属主变成了 root。这种情况在纯命令行时代一样会遇到，并不是 BrewUI 的锅。
排查思路是这样：先在终端跑一条brew doctor，看它有没有报告目录属主异常；再确认确实是权限问题之后，才建议执行修复命令：
sudo chown -R "$(whoami)" /opt/homebrew这条命令要慎用，只在brew doctor明确提示属主有问题时才执行。如果问题依旧，可以再看一眼是不是 macOS 的 SIP 或安全策略在拦截，而不是盲目地递归改权限，否则可能掩盖真正的原因。
4.2 界面状态和终端不同步，怎么办
有几次我在 BrewUI 里看到某个包“可更新”，切到终端跑brew outdated却显示没有更新。反过来也有过，终端刚手动升级完，BrewUI 还停留在旧状态。原因是 BrewUI 的本地元数据缓存和 Homebrew 的仓库状态之间存在延迟，它不会实时监听终端里的每一次变化。
解决方法其实很简单：点右上角的刷新按钮。如果还是没有变化，可以去设置里触发一次“强制重载”，这个动作会重新执行brew update然后再跑一遍完整扫描。类似的，“已安装”列表偶尔会多出一两个包，通常是因为你在另一个终端窗口里装了新东西，BrewUI 没收到通知。它本身不监听文件系统事件，只在手动刷新和特定操作之后才重新读取数据。用习惯了以后，我养成了一个习惯：每次在终端里手动执行过brew命令，回到 BrewUI 第一件事就是按一下刷新键。
4.3 卡在 Updating Homebrew 不动了
BrewUI 在安装和升级前默认会先执行brew update，这一步如果遇到访问软件仓库的网络状况不佳，就会卡很久，界面看起来像是死掉了。终端用户可以设置HOMEBREW_NO_AUTO_UPDATE=1环境变量来跳过自动更新，BrewUI 的设置里也提供了对应的开关，位置在“通用”分栏下，名字就叫“操作前自动更新”。
我的建议是：如果你的网络访问软件仓库本身速度正常，就保持这个开关打开；如果经常卡在这一步，就把它关掉，改成每隔几天在 BrewUI 里手动点一次“检查可更新版本”。这样既不会让每次安装都等半天，又能保证更新信息不会太陈旧。
另外，如果你的网络环境访问国外软件仓库整体偏慢，可以考虑把 Homebrew 的下载源切换到国内镜像。清华 TUNA 和中科大 USTC 都有完整的配置说明，这个配置属于 Homebrew 本身层面的修改，改完以后 BrewUI 会自动继承，不需要在应用里额外设置。
4.4 卸载后残留文件还在，怎么回事
卸载一个 cask 应用后，BrewUI 会照常清理掉它安装在/Applications下的主程序，但有些应用的配置文件放在~/Library/Application Support下。Homebrew 的设计原则是不主动删除用户数据，所以这类残留需要你自己处理。BrewUI 的包详情页会列出这个包的“已知文件列表”，虽然是给开发者看的，但普通用户也可以参考它来判断哪些目录可以手动删除。
我个人的习惯是：卸载重要软件之后不急着删配置目录，先重启一次确认没有影响，隔几天再回来删。毕竟配置文件里可能还有账号缓存、授权文件、本地调试记录，一旦误删，恢复的成本可能比磁盘空间本身更贵。
5. 用 BrewUI 这段时间，我的几点体会
5.1 换机场景：用 Brewfile 一键同步环境
使用 BrewUI 这两个月，最明显的感受是它把我从“背命令”的焦虑里解放了出来。以前我在一台新电脑上配环境，要先回忆旧机器上都装了哪些包，再逐个敲brew install；现在我是先打开 BrewUI 看一眼旧机器的“已安装”页面，勾选以后直接就能在新机器上一键还原。
这里要重点提一下 Brewfile。BrewUI 支持把当前已安装的所有 formula 和 cask 导出成一个Brewfile文件，这个文件本质上是一个软件清单，记录了你环境的完整组成。换新机器的时候，只要在新机器上装好 Homebrew，再把这份清单放到当前目录，终端里执行一条：
brew bundle就会按照清单把软件全部装回来。这个流程对开发者换机特别友好，BrewUI 的导出功能把这个能力从命令行带到了图形界面里，点几下鼠标就能搞定，省去了记命令和拼路径的麻烦。
5.2 什么场景下我仍然切回命令行
不过我也要泼一点冷水：BrewUI 不是万能的，有些场景下命令行依然更高效。比如通过 SSH 操作远程服务器的时候，图形界面根本用不了；再比如需要精确控制安装参数、批量处理几十个包的时候，脚本加循环远比一个一个点按钮快。BrewUI 对我来说是一个“新增的选项”，而不是“唯一的通道”。
最舒服的使用方式，是把它定位成日常装机、清理、查看状态的助理：主界面开着，装个包、清个缓存用它点几下；到了要写脚本、批量操作、排查复杂依赖问题的时候，再回到终端敲命令。这两种方式互补存在，而不是互相替代。
工具也好，方案也好，最终都是为了让自己对系统的掌控感更强。找到一个让你用得顺手、心里有数的组合，比纠结哪个工具更“高级”重要得多。
