1. 为什么有了 Homebrew 还需要一个图形界面1.1 命令行真的这么可怕吗——大多数人的真实卡点先聊句实在话在 macOS 上做开发或者折腾电脑Homebrew 基本是绕不开的一个东西。装 Python、装 Node、装 Redis、装 Nginx甚至装 Chrome、VS Code 这类带图标的软件很多人第一反应都是“先 brew install 一把”。但我和不少非专业开发者、刚转行的朋友聊过之后发现Homebrew 对他们来说并没有那么友好。倒不是命令本身多难而是“记不住”和“不敢敲”。比如我见过有人为了装一个 Git在终端里敲了brew install git然后因为网络问题卡住了当场就慌了生怕把系统搞坏还有人根本分不清brew update和brew upgrade的区别每次都是凭感觉乱敲一通。更常见的情况是软件卸载不干净装过的包越积越多磁盘空间被占掉一大块却不知道从哪下手清理。你天天用命令行当然觉得这些都是小菜一碟但换个视角想如果有一个工具能把“装软件、卸载软件、看哪些软件需要更新、清理旧版本”这些高频操作都放到一个可视化界面里点一下按钮就完成那学习成本是不是瞬间就降下来了这就是 BrewUI 这种东西存在的意义。最近 brewui 这个关键词在开发者社群里讨论度一下子高了起来核心原因就是它切中了“想用 Homebrew 但不想背命令”的这批人的真实需求。它不是要替代 Homebrew而是给 Homebrew 套一个更友好的壳让你不用每件事都去终端里敲命令。1.2 BrewUI 到底是什么它解决了什么问题简单说BrewUI 就是一个 Homebrew 的图形化管理工具。Homebrew 本身是命令行工具BrewUI 则把你日常最常用的操作全部搬到了界面上浏览软件包、搜索包、安装、卸载、升级、清理缓存、管理后台服务你都能通过鼠标点击完成。我自己的体会是它最核心的价值有三个方面。第一降低入门门槛。以前你需要在终端里记住各种子命令现在打开 BrewUI 就能看到自己装了哪些软件、哪些有更新、哪些已经过时了信息呈现得非常直观不需要去背任何命令。第二减少误操作。命令行里brew uninstall敲错了包名可能就把不该删的依赖给一起删了。但在 BrewUI 里卸载之前会明确显示这个包被哪些软件依赖你有一个确认的过程误操作的概率小很多。第三让“维护系统”这件事变得可视化。Homebrew 用久了之后难免会有一堆不再需要的旧版本、缓存文件命令行里用brew cleanup和brew autoremove虽然能清理但很多人根本不知道这两个命令的存在。BrewUI 会把“可清理的空间”直接显示出来用一个按钮就能搞定这比记命令直观太多了。不过这里要先说明一下我的立场BrewUI 不是万能的它适合日常 80% 的操作但遇到复杂的依赖冲突、需要调试的问题你还是得回到终端里去处理。所以这篇文章的目标读者是两类人一类是想用 Homebrew 但不太熟悉命令行的新朋友另一类是已经熟悉命令行的老手想找个更高效的方式管理 Mac 上的软件环境。两种人看这篇文章能拿走的东西不太一样但都有价值。2. 安装 BrewUI 和上手之前的准备2.1 环境要求与安装方式在装 BrewUI 之前你机器上得先有 Homebrew 本身。这个前提很重要因为 BrewUI 本质上只是 Homebrew 的一个前端界面它自己并不负责底层操作所有实际动作最终都是调用 Homebrew 来完成的。所以如果你还没有装过 Homebrew先打开终端执行官方安装命令/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)安装过程中它会要求你输入用户密码用来设置目录权限这是正常现象。装完之后建议先跑一遍brew doctor它会告诉你当前环境有没有什么明显的兼容性问题比如目录权限不对、依赖缺失之类顺手把这些问题清掉再用 BrewUI 会顺畅很多。BrewUI 支持的安装方式我在实际体验中主要是两种一种是通过 Homebrew 的 Cask 安装另一种是从 GitHub Releases 页面下载编译好的 dmg 包直接拖进“应用程序”。如果你本身就在用 Homebrew推荐直接用 Cask 方式安装一条命令的事brew install --cask brewui这样后续升级也方便直接brew upgrade --cask brewui就能更新到新版本。但如果你是第一次接触这类 GUI 工具、对命令行还比较畏惧我反而建议你直接去下载 dmg 包安装因为整个过程跟装微信、装 QQ 没区别没有任何心理负担。安装完成之后直接从启动台或者“应用程序”文件夹打开就行不需要特殊配置。需要留意的是BrewUI 对系统版本有一定要求它基于较新的 SwiftUI 框架开发所以 macOS 版本太老的话可能跑不起来。我实测下来 12 以上的系统基本没问题再老一些的版本如果打不开大概率就是系统版本不满足要求升级系统或者换回命令行就好。2.2 第一次打开界面里都有什么BrewUI 的界面其实不复杂第一次打开稍微花 30 秒扫一遍就能上手但我还是想按实际操作顺序拆一下免得你打开之后一脸懵。整体布局大概是这样的左侧是分类导航右侧是主内容区所有信息都以列表和卡片的形式呈现。左侧导航栏里你会看到几个核心模块——已安装的包、可更新的包、全部软件包、搜索结果、以及服务管理页。不同版本的具体叫法可能略有差异但功能分类基本逃不开这几个大方向。先看“已安装”这块它会把所有通过 Homebrew 安装的 Formula命令行工具比如 git、node、wget 这些和 Cask图形应用比如 Chrome、VS Code 这些统一列出来。每个条目会显示软件名、当前版本、是否有更新等信息右上角可能还带一个卸载按钮。这个页面能让你一眼看到自己这台机器上到底装了多少东西、都是什么版本比在终端里敲brew list再一个个查版本号直观得多。再看“可更新”这个模块它是日常使用频率最高的一个页面。只要 Homebrew 有包发布了新版本这里就会列出来并且会显示当前版本和目标版本你只需要点击更新即可。这个设计对“懒得定期敲brew upgrade”的人来说特别友好因为它把所有待更新的软件集中展示你不会漏掉任何一项。顶部一般还有一个全局搜索框。搜索的用途很直接——你想装什么新软件比如搜索“nginx”结果会显示哪些软件包跟它相关每个候选包会标明是 Formula 还是 Cask点进去还能看到描述信息。选中之后界面上会有明确的安装按钮整个过程不需要离开界面。服务管理页则是对应命令行里的brew services系列命令。你装的那些数据库、Web 服务器之类需要常驻后台的程序在这里都能看到运行状态可以用开关直接启动、停止甚至设置开机自启。我自己日常用的 MySQL、Redis 就是在这里管理的比记brew services start mysql这类命令省心不少。3. 核心功能实操从装包到清内存3.1 搜索并安装一个软件包安装新软件是 BrewUI 最基础的使用场景我以装一个“nginx”为例把整个流程走一遍给你看。打开 BrewUI在顶部搜索框里输入nginx稍等片刻搜索结果就会列出来。你会发现 nginx 相关的条目有好几个有核心的nginx包也有扩展模块和第三方发行版。这时候很多人会困惑搜出一堆差不多名字的到底装哪个判断的方法很简单优先看旁边标注的类型和描述。标着 Formula 的那个一般是官方默认包描述里通常写得比较清晰比如“nginx- 高性能 Web 服务器和维护者” 这种基本不会错。你要是想装带某些特殊模块的版本那得看清楚描述里承诺了哪些功能但这就属于进阶玩法了新手不用纠结。选定目标之后点击安装按钮。这时候 BrewUI 会调用 Homebrew 去实际执行安装你可能会看到界面里出现一段日志流包括下载进度、依赖解析、编译过程等等。第一次装比较大的包时这个过程可能持续几分钟你不需要一直盯着等它跑完就行。有一点要提醒的是安装期间别中途强退 BrewUI虽然理论上不一定会出问题但我实测过有些包装了半截被中断后面修复比重装还麻烦。安装完成之后这个包会立刻出现在“已安装”列表里同时状态栏会标出当前版本号。到这一步你其实已经完成了“找到软件、安装软件、确认装好”的完整闭环全程没有敲过一行命令。不过这里有个我踩过的坑得专门说一下装 Cask 类型的图形软件比如从 BrewUI 里装 Chrome 或 微信本质上等同于从一个磁盘映像里复制应用程序到“应用程序”文件夹。所以如果你之前已经手动装过同一个软件有可能会出现“版本冲突”或者“同名应用已存在”的提示。这时候别慌随便选一个方向处理要么先在 BrewUI 里卸载旧版本再重新安装新版本要么干脆跳过安装手动更新一下就好BrewUI 不背这个锅。3.2 更新与升级一键处理还是分批处理软件更新是很多人最关心的功能因为 Homebrew 的命令行更新机制对新手来说确实容易搞混。brew update是更新 Homebrew 自身的索引信息brew upgrade才是真正升级那些已安装的软件包。有人不知道这个区别天天敲brew update结果软件版本一直不变还以为自己操作有问题——说白了就是命令搞混了。在 BrewUI 里更新逻辑就直白多了“可更新”页面把所有有新版本的包都列出来每个包后面带有更新按钮。你既可以一个包一个包地选择升级也可以在页面右上角找到一键更新全部。这个设计我觉得特别合理因为不同软件对升级的敏感度完全不一样有的人希望所有软件都保持最新有的人则担心某个软件升级后跟现有环境不兼容想要控制节奏。分批升级给了你选择的余地。我自己的使用习惯是这样的日常小版本更新比如某个工具库从 1.2.3 升到 1.2.4这类更新基本是修 Bug风险极低我会直接一键全部更新但如果是主版本更新比如从 2.x 升到 3.x我一般会先去官网看一眼变更日志确认没有破坏性变更之后才单独升级那一个包。主版本升级经常伴随配置格式变化、API 调整这些在 Web 服务端软件里尤其需要谨慎。升级过程中同样会展示日志你可以实时看到它在下载什么、编译什么。有一点很关键升级依赖了一大堆的包比如 Python 的某个库升级可能会连带升级几个底层依赖包。BrewUI 会把依赖关系处理得很好但处理时间会相应变长这都是正常的。我看到有人以为卡死了就强制退出结果升级到一半包的状态变得很诡异后面还得手动修复这比一开始就耐心等要麻烦得多。还有个细节值得说BrewUI 里的“更新”按钮和 macOS 系统更新完全是两回事。它只管 Homebrew 管的那部分软件不会帮你升级 macOS 系统本身更不会动 App Store 里的应用。这个边界搞清楚你就不会对它产生错误的预期。3.3 卸载与清理把磁盘空间找回来卸载软件听起来是个简单的事情但“干净”地卸载其实是门学问。命令行里brew uninstall会删除软件本体但不一定会动它留下的配置文件和数据文件。这些文件虽然单个不大但日积月累也会变成一堆垃圾占用不少磁盘空间。在 BrewUI 里卸载流程是可视化的。你进入“已安装”列表找到想要卸载的软件点击卸载按钮通常会弹出一个确认对话框上面会写明这个包被哪些其他软件所依赖。这个信息非常关键比如某个底层库被三个应用程序共用你要是贸然把它卸了其他三个可能就运行不正常。有了依赖提示你至少能做出一个知情决定而不是迷迷糊糊就把地基建给挖了。卸完之后BrewUI 一般还会提示你是否有残留的旧版本或者孤立依赖需要清理。这里有两个概念可以顺便解释一下旧版本指的是同一个软件装过的历史版本Homebrew 为了切换版本可能会保留它们孤立依赖指的是当初为了安装 A 而被自动装上的依赖库现在 A 已经卸了它们就成了没人引用的“孤儿”。清理这些垃圾就是brew cleanup和brew autoremove这两个命令干的事在图形界面里可能表现为一个“清理空间”按钮。如果你发现 Mac 的磁盘空间越来越紧但翻遍“应用程序”文件夹也没找到几个大块头罪魁祸首往往就是你用 Homebrew 装的这些命令行工具和它们的依赖库。我见过有人一台 256G 的机器光 Homebrew 目录就占了 30 多个 G里面绝大多数都是各种依赖的历史版本。这种情况用 BrewUI 里的清理功能跑一遍能瞬间释放好几个 G 的空间体验非常直观。清理这个动作看起来轻飘飘实际上风险并不低。我遇到过清理之后某个软件跑不起来的情况原因是它的运行依赖被判定成了“孤立”而误清了。虽然 Homebrew 在设计上已经尽量规避这种风险但极端场景下仍然可能发生。所以我的建议是清理之前先大概看一眼它会清哪些东西遇到不认识的包名可以先搜一下再决定要不要继续。另外Windows 上装过的某些 Docker 容器、虚拟机镜像这类体积巨大的文件不属于 Homebrew 目录BrewUI 再厉害也帮不上忙你要找空间还是得自己手动处理那一部分。3.4 管理服务Services数据库和后台进程的图形化开关Homebrew 的brew services系列命令是一个很强大但很多人不知道的功能。简单说它可以把某个软件注册成 macOS 的后台服务由系统统一管理做到开机自启、崩溃自动拉起。这在跑数据库、Web 服务时特别实用。命令行里的用法是这样的brew services start mysql brew services stop mysql brew services list说实话这三条命令本身不算难记但如果你管理好几个服务还要经常查看它们的运行状态命令行就变得不太直观了。BrewUI 把这一切图形化之后体验确实好了不少。在服务管理页面你会看到所有通过 Homebrew 注册了服务的软件每个都带有一个当前状态标签比如“已停止”或者“运行中”。你要启动 MySQL就在它那一栏点一下启动开关状态马上变化要停止再点一下。界面里还能直接设置是否开机自启这个对应命令行里的brew services run和brew services start的区别——一个只管当前会话一个要长期驻留。我自己日常用得最多的场景就是本地开发环境同时跑着 MySQL 和 Redis以前每次开机都得手动敲一遍启动命令或者依赖各种乱七八糟的启动脚本。用 BrewUI 之后我在服务页面把两个服务都设成了开机自启之后每次开机它们就自动在后台跑着再也不用管了。想临时停掉某一个打开 BrewUI 点一下开关就行比敲命令快多了也不太容易因为打错字母导致操作失败。服务管理还有一个隐含的好处它能非常直观地展示“哪些服务占着你的端口”。比如你启动服务的时候发现 3306 或者 6379 端口被占用到 BrewUI 的服务列表里看一遍每个服务当前的状态马上就知道是谁在占着。当然这种排查方式不能覆盖所有情况比如 Docker 容器也占端口但它不会出现在 BrewUI 里但对于 Homebrew 管理的服务来说这个判断路径确实最高效。4. 实际使用中的常见问题和排查技巧4.1 “Command not found” 和权限问题我接触的很多刚使用 Homebrew 的人遇到的第一大坑是安装完一个软件之后在终端里敲这个软件的命令结果提示command not found。很多人第一反应是“装失败了”其实多半是因为 Homebrew 的安装路径没有加到系统 PATH 环境变量里。Apple Silicon 芯片的 MacHomebrew 默认安装路径是/opt/homebrew对应的 shell 配置文件里需要有一行/opt/homebrew/bin的 PATH 声明。如果你刚装完 Homebrew 就直奔 BrewUI 装软件装完发现终端里找不到命令请优先检查这个。命令行方案是执行echo eval $(/opt/homebrew/bin/brew shellenv) ~/.zprofile然后重启终端。另一类常见问题是权限错误。比如你在终端里执行brew cleanup或者某些安装操作时提示Permission denied dir_s_mkdir或者/opt/homebrew is not writable。这个问题的本质是 Homebrew 目录的所有权变了通常是因为你用sudo执行过某些命令把目录的所有者改成了 root。修复方法也比较直接把目录所有权重新改回当前用户sudo chown -R $USER:admin /opt/homebrewBrewUI 本身一般不直接处理这类底层权限问题但它能起到“告警”作用——比如某个包的更新反复失败、状态异常往往底层就是权限问题在捣乱。你可以在确认 Homebrew 相关目录权限无误之后再重试操作绝大部分问题都能解决。4.2 下载慢、源不稳定怎么办国内用户使用 Homebrew 时最头痛的问题之一就是下载速度。这个锅通常不在 Homebrew 本身而在于默认的软件源服务器在国外网络质量不稳定的时候安装一个包可能要卡几分钟甚至更久。BrewUI 里看到的“安装卡住”“进度条不动”很多时候就是这个原因。社区里的常规解法是更换软件源把默认源换成国内的一些镜像源。常见的选择有中科大镜像、清华镜像等。切换方式不复杂核心是执行几条git remote set-url类型的命令和设置环境变量把 Homebrew 的仓库地址指向镜像。换源操作本身在终端里执行BrewUI 不需要额外配置因为底层调用的还是 Homebrew源换好之后BrewUI 里的安装和更新速度自然就快了。改完之后记得跑一下brew update让索引刷新再回到 BrewUI 里看速度差别。这里有个实操经验换完源之后如果你当前的 Homebrew 已经是很老的版本可能需要先升级一次自身的索引才能和镜像源正常同步。如果升级过程报错可以把cd $(brew --repo)进去手动重置一下远端地址再重新更新问题一般都能化解。4.3 依赖冲突和装了一半的包依赖冲突是 Homebrew 环境里最让人头疼的问题之一。比如你要装 AA 依赖 B 的 2.0 版本但系统里已经有一个 CC 却要求只能用 B 的 1.5 版本。这种冲突在命令行下会直接报错提示信息又长又绕新手看了基本是懵的。BrewUI 的优势在于它会在安装之前尽量把依赖关系展示清楚让你知道这个包要带动哪些依赖一起装。你可以提前判断这些依赖会不会跟现有环境打架比如某些底层库出现了多个大版本共存的情况图形界面会列出两个版本的下载和安装过程你不需要自己干预。但万一真的遇上装到一半报错的情况该怎么办首先不要慌不要立刻重试。我的建议是先把报错信息完整截图或者复制下来然后自己看一眼里面有没有关键提示。常见的有“sha256 mismatch”——说明下载包校验不一致通常是源的问题更换镜像源后重新装就行还有“make install failed”——说明编译过程出了问题一般跟系统 SDK 版本有关可以尝试更新系统开发工具再装。装了一半导致包状态异常的另一个解法是把安装过程回滚。命令行里有brew reinstall可以强制重装在 BrewUI 里通常表现为对特定包再做一次安装操作它会自动覆盖掉残缺状态。如果连重装都报同样错误那你多半遇到了依赖死锁或者底层环境问题这时候就乖乖回到终端里执行brew doctor看它给出的修复建议用最笨但最可靠的方式逐个修复。说实话BrewUI 在正常路径下很好用但这类“非正常路径”的修复目前还是命令行工具的主场。4.4 哪些事情别用 BrewUI 硬扛写到这里我觉得有必要把 BrewUI 的能力边界讲清楚省得有人把它当成万能工具。第一类场景是复杂依赖的深度调整。比如你想给某个软件指定一个非默认版本的依赖或者你想从源码编译一个自定义配置的版本这些在 BrewUI 里基本做不了或者说即便能做也不推荐。这些操作本来就是 Homebrew 的公式定义的另类用法用命令行手动控制“安装模式”会更直接。第二类是批量初始化环境。如果你要在一台新 Mac 上快速恢复一整套开发环境比如十好几个工具加上多个服务用 BrewUI 一个点一个点去装效率远不如写好一个 BrewfileHomebrew 的自动化安装清单然后直接跑brew bundle命令。我之前介绍过这个用法它是 Homebrew 里被严重低估的自动化利器配合脚本使用新环境半小时内就能恢复大部分生产力。第三类是排查底层网络问题。你发现某些包反复下载失败、某些仓库拉不下来这些问题根源大多是网络配置或者 DNS 问题。BrewUI 能看到的只是表象你需要在终端里用ping、curl、git fetch这一系列工具去判断网络链路的哪个环节出了问题GUI 帮不了你。所以我对 BrewUI 的定位从来都是“日常管理工具”它让你 80% 的软件环境维护工作变得轻松直观剩下 20% 的技术活还是得你自己到终端里去修炼。这不是缺陷而是工具分工的正常逻辑。5. 适合哪些人、不太适合哪些人5.1 推荐使用的人群我最推荐优先尝试 BrewUI 的是这几类人刚接触开发环境的新朋友。如果你连环境变量、源代码编译、包管理器这些概念都还不太熟悉命令行里全是黑底白字一个失误就可能让人忐忑半天。BrewUI 可以让你在图形界面里完成大部分软件安装和维护操作至少不会因为敲错命令而产生额外挫败感。你在界面里看到“依赖”“缓存”“服务”这些概念天然比在终端里面对大段日志更容易建立直觉。日常要多台机器管理软件环境的开发者。比如你手上有自己的 MacBook还经常需要在公司电脑上装一套类似的开发环境。BrewUI 让你可以直观地看到两台机器各自装了哪些包、版本有什么差异比开两个终端窗口来回敲brew list高效多了。电脑硬盘空间经常告急的普通用户。很多人不肯用命令行也不愿意研究磁盘里到底什么东西占了空间。BrewUI 把“可清理项”直接列出来一键就能清掉一堆旧版本和缓存对磁盘焦虑症患者来说就是解压神器。5.2 不建议使用的人群反过来也有几类人其实不太需要 BrewUI。第一类是已经把 Homebrew 命令掌握得很熟的老手。他们敲命令的速度比打开 GUI 还快而且经常要写脚本进行批量操作GUI 反而会成为效率瓶颈。这类人不是 BrewUI 的目标用户但可以作为工具推荐给身边的新手朋友。第二类是需要高度自定义软件环境的人。如果你经常需要编译定制版本的软件、打各种编译参数甚至自己写 Homebrew 公式那命令行的自由度和灵活性远远不是 GUI 能比的。用 BrewUI 去干这种活等于拿自动挡去跑越野。第三类是极简主义者——就是那种追求“机器上越干净越好能少装一个软件就少装一个”的人。如果你衡量之后觉得一个月就装两三次软件几十条常用命令已经背得滚瓜烂熟那 BrewUI 对你来说确实可有可无。它解决的是“频繁管理”的痛点使用频次不够高的话多一个软件反而成了心理负担。写在最后的一点个人体会文章写到这儿按理说该总结的都总结完了。我个人在这个工具上实际体验下来的结论是它不是一个“炫技”型工具而是一个“减负”型工具。所谓减负不是让大家从此不学命令行而是把那些机械、重复、低认知难度的日常操作解放出来让你把时间和注意力留给真正需要动脑的问题。如果你刚开始接触 Homebrew或者你身边有人在用 Homebrew 但一直对它敬而远之不妨把 BrewUI 推荐给他让他从“敢装软件”开始慢慢理解包管理器的工作原理。从界面回到命令行永远比从命令行硬啃界面要容易得多。最后再分享一个小技巧就算你主力用 BrewUI也别完全丢掉终端。你可以在终端里敲一下brew list --versions看看系统里所有软件的最新版本清单再敲一下brew deps --tree --installed看看依赖树长得什么样。这些“可视化能力”反而是命令行模式下的独特优势两者结合使用比单纯依赖任何一种方式都更舒服。
BrewUI：给Homebrew套上友好图形界面，让macOS软件管理更简单
1. 为什么有了 Homebrew 还需要一个图形界面1.1 命令行真的这么可怕吗——大多数人的真实卡点先聊句实在话在 macOS 上做开发或者折腾电脑Homebrew 基本是绕不开的一个东西。装 Python、装 Node、装 Redis、装 Nginx甚至装 Chrome、VS Code 这类带图标的软件很多人第一反应都是“先 brew install 一把”。但我和不少非专业开发者、刚转行的朋友聊过之后发现Homebrew 对他们来说并没有那么友好。倒不是命令本身多难而是“记不住”和“不敢敲”。比如我见过有人为了装一个 Git在终端里敲了brew install git然后因为网络问题卡住了当场就慌了生怕把系统搞坏还有人根本分不清brew update和brew upgrade的区别每次都是凭感觉乱敲一通。更常见的情况是软件卸载不干净装过的包越积越多磁盘空间被占掉一大块却不知道从哪下手清理。你天天用命令行当然觉得这些都是小菜一碟但换个视角想如果有一个工具能把“装软件、卸载软件、看哪些软件需要更新、清理旧版本”这些高频操作都放到一个可视化界面里点一下按钮就完成那学习成本是不是瞬间就降下来了这就是 BrewUI 这种东西存在的意义。最近 brewui 这个关键词在开发者社群里讨论度一下子高了起来核心原因就是它切中了“想用 Homebrew 但不想背命令”的这批人的真实需求。它不是要替代 Homebrew而是给 Homebrew 套一个更友好的壳让你不用每件事都去终端里敲命令。1.2 BrewUI 到底是什么它解决了什么问题简单说BrewUI 就是一个 Homebrew 的图形化管理工具。Homebrew 本身是命令行工具BrewUI 则把你日常最常用的操作全部搬到了界面上浏览软件包、搜索包、安装、卸载、升级、清理缓存、管理后台服务你都能通过鼠标点击完成。我自己的体会是它最核心的价值有三个方面。第一降低入门门槛。以前你需要在终端里记住各种子命令现在打开 BrewUI 就能看到自己装了哪些软件、哪些有更新、哪些已经过时了信息呈现得非常直观不需要去背任何命令。第二减少误操作。命令行里brew uninstall敲错了包名可能就把不该删的依赖给一起删了。但在 BrewUI 里卸载之前会明确显示这个包被哪些软件依赖你有一个确认的过程误操作的概率小很多。第三让“维护系统”这件事变得可视化。Homebrew 用久了之后难免会有一堆不再需要的旧版本、缓存文件命令行里用brew cleanup和brew autoremove虽然能清理但很多人根本不知道这两个命令的存在。BrewUI 会把“可清理的空间”直接显示出来用一个按钮就能搞定这比记命令直观太多了。不过这里要先说明一下我的立场BrewUI 不是万能的它适合日常 80% 的操作但遇到复杂的依赖冲突、需要调试的问题你还是得回到终端里去处理。所以这篇文章的目标读者是两类人一类是想用 Homebrew 但不太熟悉命令行的新朋友另一类是已经熟悉命令行的老手想找个更高效的方式管理 Mac 上的软件环境。两种人看这篇文章能拿走的东西不太一样但都有价值。2. 安装 BrewUI 和上手之前的准备2.1 环境要求与安装方式在装 BrewUI 之前你机器上得先有 Homebrew 本身。这个前提很重要因为 BrewUI 本质上只是 Homebrew 的一个前端界面它自己并不负责底层操作所有实际动作最终都是调用 Homebrew 来完成的。所以如果你还没有装过 Homebrew先打开终端执行官方安装命令/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)安装过程中它会要求你输入用户密码用来设置目录权限这是正常现象。装完之后建议先跑一遍brew doctor它会告诉你当前环境有没有什么明显的兼容性问题比如目录权限不对、依赖缺失之类顺手把这些问题清掉再用 BrewUI 会顺畅很多。BrewUI 支持的安装方式我在实际体验中主要是两种一种是通过 Homebrew 的 Cask 安装另一种是从 GitHub Releases 页面下载编译好的 dmg 包直接拖进“应用程序”。如果你本身就在用 Homebrew推荐直接用 Cask 方式安装一条命令的事brew install --cask brewui这样后续升级也方便直接brew upgrade --cask brewui就能更新到新版本。但如果你是第一次接触这类 GUI 工具、对命令行还比较畏惧我反而建议你直接去下载 dmg 包安装因为整个过程跟装微信、装 QQ 没区别没有任何心理负担。安装完成之后直接从启动台或者“应用程序”文件夹打开就行不需要特殊配置。需要留意的是BrewUI 对系统版本有一定要求它基于较新的 SwiftUI 框架开发所以 macOS 版本太老的话可能跑不起来。我实测下来 12 以上的系统基本没问题再老一些的版本如果打不开大概率就是系统版本不满足要求升级系统或者换回命令行就好。2.2 第一次打开界面里都有什么BrewUI 的界面其实不复杂第一次打开稍微花 30 秒扫一遍就能上手但我还是想按实际操作顺序拆一下免得你打开之后一脸懵。整体布局大概是这样的左侧是分类导航右侧是主内容区所有信息都以列表和卡片的形式呈现。左侧导航栏里你会看到几个核心模块——已安装的包、可更新的包、全部软件包、搜索结果、以及服务管理页。不同版本的具体叫法可能略有差异但功能分类基本逃不开这几个大方向。先看“已安装”这块它会把所有通过 Homebrew 安装的 Formula命令行工具比如 git、node、wget 这些和 Cask图形应用比如 Chrome、VS Code 这些统一列出来。每个条目会显示软件名、当前版本、是否有更新等信息右上角可能还带一个卸载按钮。这个页面能让你一眼看到自己这台机器上到底装了多少东西、都是什么版本比在终端里敲brew list再一个个查版本号直观得多。再看“可更新”这个模块它是日常使用频率最高的一个页面。只要 Homebrew 有包发布了新版本这里就会列出来并且会显示当前版本和目标版本你只需要点击更新即可。这个设计对“懒得定期敲brew upgrade”的人来说特别友好因为它把所有待更新的软件集中展示你不会漏掉任何一项。顶部一般还有一个全局搜索框。搜索的用途很直接——你想装什么新软件比如搜索“nginx”结果会显示哪些软件包跟它相关每个候选包会标明是 Formula 还是 Cask点进去还能看到描述信息。选中之后界面上会有明确的安装按钮整个过程不需要离开界面。服务管理页则是对应命令行里的brew services系列命令。你装的那些数据库、Web 服务器之类需要常驻后台的程序在这里都能看到运行状态可以用开关直接启动、停止甚至设置开机自启。我自己日常用的 MySQL、Redis 就是在这里管理的比记brew services start mysql这类命令省心不少。3. 核心功能实操从装包到清内存3.1 搜索并安装一个软件包安装新软件是 BrewUI 最基础的使用场景我以装一个“nginx”为例把整个流程走一遍给你看。打开 BrewUI在顶部搜索框里输入nginx稍等片刻搜索结果就会列出来。你会发现 nginx 相关的条目有好几个有核心的nginx包也有扩展模块和第三方发行版。这时候很多人会困惑搜出一堆差不多名字的到底装哪个判断的方法很简单优先看旁边标注的类型和描述。标着 Formula 的那个一般是官方默认包描述里通常写得比较清晰比如“nginx- 高性能 Web 服务器和维护者” 这种基本不会错。你要是想装带某些特殊模块的版本那得看清楚描述里承诺了哪些功能但这就属于进阶玩法了新手不用纠结。选定目标之后点击安装按钮。这时候 BrewUI 会调用 Homebrew 去实际执行安装你可能会看到界面里出现一段日志流包括下载进度、依赖解析、编译过程等等。第一次装比较大的包时这个过程可能持续几分钟你不需要一直盯着等它跑完就行。有一点要提醒的是安装期间别中途强退 BrewUI虽然理论上不一定会出问题但我实测过有些包装了半截被中断后面修复比重装还麻烦。安装完成之后这个包会立刻出现在“已安装”列表里同时状态栏会标出当前版本号。到这一步你其实已经完成了“找到软件、安装软件、确认装好”的完整闭环全程没有敲过一行命令。不过这里有个我踩过的坑得专门说一下装 Cask 类型的图形软件比如从 BrewUI 里装 Chrome 或 微信本质上等同于从一个磁盘映像里复制应用程序到“应用程序”文件夹。所以如果你之前已经手动装过同一个软件有可能会出现“版本冲突”或者“同名应用已存在”的提示。这时候别慌随便选一个方向处理要么先在 BrewUI 里卸载旧版本再重新安装新版本要么干脆跳过安装手动更新一下就好BrewUI 不背这个锅。3.2 更新与升级一键处理还是分批处理软件更新是很多人最关心的功能因为 Homebrew 的命令行更新机制对新手来说确实容易搞混。brew update是更新 Homebrew 自身的索引信息brew upgrade才是真正升级那些已安装的软件包。有人不知道这个区别天天敲brew update结果软件版本一直不变还以为自己操作有问题——说白了就是命令搞混了。在 BrewUI 里更新逻辑就直白多了“可更新”页面把所有有新版本的包都列出来每个包后面带有更新按钮。你既可以一个包一个包地选择升级也可以在页面右上角找到一键更新全部。这个设计我觉得特别合理因为不同软件对升级的敏感度完全不一样有的人希望所有软件都保持最新有的人则担心某个软件升级后跟现有环境不兼容想要控制节奏。分批升级给了你选择的余地。我自己的使用习惯是这样的日常小版本更新比如某个工具库从 1.2.3 升到 1.2.4这类更新基本是修 Bug风险极低我会直接一键全部更新但如果是主版本更新比如从 2.x 升到 3.x我一般会先去官网看一眼变更日志确认没有破坏性变更之后才单独升级那一个包。主版本升级经常伴随配置格式变化、API 调整这些在 Web 服务端软件里尤其需要谨慎。升级过程中同样会展示日志你可以实时看到它在下载什么、编译什么。有一点很关键升级依赖了一大堆的包比如 Python 的某个库升级可能会连带升级几个底层依赖包。BrewUI 会把依赖关系处理得很好但处理时间会相应变长这都是正常的。我看到有人以为卡死了就强制退出结果升级到一半包的状态变得很诡异后面还得手动修复这比一开始就耐心等要麻烦得多。还有个细节值得说BrewUI 里的“更新”按钮和 macOS 系统更新完全是两回事。它只管 Homebrew 管的那部分软件不会帮你升级 macOS 系统本身更不会动 App Store 里的应用。这个边界搞清楚你就不会对它产生错误的预期。3.3 卸载与清理把磁盘空间找回来卸载软件听起来是个简单的事情但“干净”地卸载其实是门学问。命令行里brew uninstall会删除软件本体但不一定会动它留下的配置文件和数据文件。这些文件虽然单个不大但日积月累也会变成一堆垃圾占用不少磁盘空间。在 BrewUI 里卸载流程是可视化的。你进入“已安装”列表找到想要卸载的软件点击卸载按钮通常会弹出一个确认对话框上面会写明这个包被哪些其他软件所依赖。这个信息非常关键比如某个底层库被三个应用程序共用你要是贸然把它卸了其他三个可能就运行不正常。有了依赖提示你至少能做出一个知情决定而不是迷迷糊糊就把地基建给挖了。卸完之后BrewUI 一般还会提示你是否有残留的旧版本或者孤立依赖需要清理。这里有两个概念可以顺便解释一下旧版本指的是同一个软件装过的历史版本Homebrew 为了切换版本可能会保留它们孤立依赖指的是当初为了安装 A 而被自动装上的依赖库现在 A 已经卸了它们就成了没人引用的“孤儿”。清理这些垃圾就是brew cleanup和brew autoremove这两个命令干的事在图形界面里可能表现为一个“清理空间”按钮。如果你发现 Mac 的磁盘空间越来越紧但翻遍“应用程序”文件夹也没找到几个大块头罪魁祸首往往就是你用 Homebrew 装的这些命令行工具和它们的依赖库。我见过有人一台 256G 的机器光 Homebrew 目录就占了 30 多个 G里面绝大多数都是各种依赖的历史版本。这种情况用 BrewUI 里的清理功能跑一遍能瞬间释放好几个 G 的空间体验非常直观。清理这个动作看起来轻飘飘实际上风险并不低。我遇到过清理之后某个软件跑不起来的情况原因是它的运行依赖被判定成了“孤立”而误清了。虽然 Homebrew 在设计上已经尽量规避这种风险但极端场景下仍然可能发生。所以我的建议是清理之前先大概看一眼它会清哪些东西遇到不认识的包名可以先搜一下再决定要不要继续。另外Windows 上装过的某些 Docker 容器、虚拟机镜像这类体积巨大的文件不属于 Homebrew 目录BrewUI 再厉害也帮不上忙你要找空间还是得自己手动处理那一部分。3.4 管理服务Services数据库和后台进程的图形化开关Homebrew 的brew services系列命令是一个很强大但很多人不知道的功能。简单说它可以把某个软件注册成 macOS 的后台服务由系统统一管理做到开机自启、崩溃自动拉起。这在跑数据库、Web 服务时特别实用。命令行里的用法是这样的brew services start mysql brew services stop mysql brew services list说实话这三条命令本身不算难记但如果你管理好几个服务还要经常查看它们的运行状态命令行就变得不太直观了。BrewUI 把这一切图形化之后体验确实好了不少。在服务管理页面你会看到所有通过 Homebrew 注册了服务的软件每个都带有一个当前状态标签比如“已停止”或者“运行中”。你要启动 MySQL就在它那一栏点一下启动开关状态马上变化要停止再点一下。界面里还能直接设置是否开机自启这个对应命令行里的brew services run和brew services start的区别——一个只管当前会话一个要长期驻留。我自己日常用得最多的场景就是本地开发环境同时跑着 MySQL 和 Redis以前每次开机都得手动敲一遍启动命令或者依赖各种乱七八糟的启动脚本。用 BrewUI 之后我在服务页面把两个服务都设成了开机自启之后每次开机它们就自动在后台跑着再也不用管了。想临时停掉某一个打开 BrewUI 点一下开关就行比敲命令快多了也不太容易因为打错字母导致操作失败。服务管理还有一个隐含的好处它能非常直观地展示“哪些服务占着你的端口”。比如你启动服务的时候发现 3306 或者 6379 端口被占用到 BrewUI 的服务列表里看一遍每个服务当前的状态马上就知道是谁在占着。当然这种排查方式不能覆盖所有情况比如 Docker 容器也占端口但它不会出现在 BrewUI 里但对于 Homebrew 管理的服务来说这个判断路径确实最高效。4. 实际使用中的常见问题和排查技巧4.1 “Command not found” 和权限问题我接触的很多刚使用 Homebrew 的人遇到的第一大坑是安装完一个软件之后在终端里敲这个软件的命令结果提示command not found。很多人第一反应是“装失败了”其实多半是因为 Homebrew 的安装路径没有加到系统 PATH 环境变量里。Apple Silicon 芯片的 MacHomebrew 默认安装路径是/opt/homebrew对应的 shell 配置文件里需要有一行/opt/homebrew/bin的 PATH 声明。如果你刚装完 Homebrew 就直奔 BrewUI 装软件装完发现终端里找不到命令请优先检查这个。命令行方案是执行echo eval $(/opt/homebrew/bin/brew shellenv) ~/.zprofile然后重启终端。另一类常见问题是权限错误。比如你在终端里执行brew cleanup或者某些安装操作时提示Permission denied dir_s_mkdir或者/opt/homebrew is not writable。这个问题的本质是 Homebrew 目录的所有权变了通常是因为你用sudo执行过某些命令把目录的所有者改成了 root。修复方法也比较直接把目录所有权重新改回当前用户sudo chown -R $USER:admin /opt/homebrewBrewUI 本身一般不直接处理这类底层权限问题但它能起到“告警”作用——比如某个包的更新反复失败、状态异常往往底层就是权限问题在捣乱。你可以在确认 Homebrew 相关目录权限无误之后再重试操作绝大部分问题都能解决。4.2 下载慢、源不稳定怎么办国内用户使用 Homebrew 时最头痛的问题之一就是下载速度。这个锅通常不在 Homebrew 本身而在于默认的软件源服务器在国外网络质量不稳定的时候安装一个包可能要卡几分钟甚至更久。BrewUI 里看到的“安装卡住”“进度条不动”很多时候就是这个原因。社区里的常规解法是更换软件源把默认源换成国内的一些镜像源。常见的选择有中科大镜像、清华镜像等。切换方式不复杂核心是执行几条git remote set-url类型的命令和设置环境变量把 Homebrew 的仓库地址指向镜像。换源操作本身在终端里执行BrewUI 不需要额外配置因为底层调用的还是 Homebrew源换好之后BrewUI 里的安装和更新速度自然就快了。改完之后记得跑一下brew update让索引刷新再回到 BrewUI 里看速度差别。这里有个实操经验换完源之后如果你当前的 Homebrew 已经是很老的版本可能需要先升级一次自身的索引才能和镜像源正常同步。如果升级过程报错可以把cd $(brew --repo)进去手动重置一下远端地址再重新更新问题一般都能化解。4.3 依赖冲突和装了一半的包依赖冲突是 Homebrew 环境里最让人头疼的问题之一。比如你要装 AA 依赖 B 的 2.0 版本但系统里已经有一个 CC 却要求只能用 B 的 1.5 版本。这种冲突在命令行下会直接报错提示信息又长又绕新手看了基本是懵的。BrewUI 的优势在于它会在安装之前尽量把依赖关系展示清楚让你知道这个包要带动哪些依赖一起装。你可以提前判断这些依赖会不会跟现有环境打架比如某些底层库出现了多个大版本共存的情况图形界面会列出两个版本的下载和安装过程你不需要自己干预。但万一真的遇上装到一半报错的情况该怎么办首先不要慌不要立刻重试。我的建议是先把报错信息完整截图或者复制下来然后自己看一眼里面有没有关键提示。常见的有“sha256 mismatch”——说明下载包校验不一致通常是源的问题更换镜像源后重新装就行还有“make install failed”——说明编译过程出了问题一般跟系统 SDK 版本有关可以尝试更新系统开发工具再装。装了一半导致包状态异常的另一个解法是把安装过程回滚。命令行里有brew reinstall可以强制重装在 BrewUI 里通常表现为对特定包再做一次安装操作它会自动覆盖掉残缺状态。如果连重装都报同样错误那你多半遇到了依赖死锁或者底层环境问题这时候就乖乖回到终端里执行brew doctor看它给出的修复建议用最笨但最可靠的方式逐个修复。说实话BrewUI 在正常路径下很好用但这类“非正常路径”的修复目前还是命令行工具的主场。4.4 哪些事情别用 BrewUI 硬扛写到这里我觉得有必要把 BrewUI 的能力边界讲清楚省得有人把它当成万能工具。第一类场景是复杂依赖的深度调整。比如你想给某个软件指定一个非默认版本的依赖或者你想从源码编译一个自定义配置的版本这些在 BrewUI 里基本做不了或者说即便能做也不推荐。这些操作本来就是 Homebrew 的公式定义的另类用法用命令行手动控制“安装模式”会更直接。第二类是批量初始化环境。如果你要在一台新 Mac 上快速恢复一整套开发环境比如十好几个工具加上多个服务用 BrewUI 一个点一个点去装效率远不如写好一个 BrewfileHomebrew 的自动化安装清单然后直接跑brew bundle命令。我之前介绍过这个用法它是 Homebrew 里被严重低估的自动化利器配合脚本使用新环境半小时内就能恢复大部分生产力。第三类是排查底层网络问题。你发现某些包反复下载失败、某些仓库拉不下来这些问题根源大多是网络配置或者 DNS 问题。BrewUI 能看到的只是表象你需要在终端里用ping、curl、git fetch这一系列工具去判断网络链路的哪个环节出了问题GUI 帮不了你。所以我对 BrewUI 的定位从来都是“日常管理工具”它让你 80% 的软件环境维护工作变得轻松直观剩下 20% 的技术活还是得你自己到终端里去修炼。这不是缺陷而是工具分工的正常逻辑。5. 适合哪些人、不太适合哪些人5.1 推荐使用的人群我最推荐优先尝试 BrewUI 的是这几类人刚接触开发环境的新朋友。如果你连环境变量、源代码编译、包管理器这些概念都还不太熟悉命令行里全是黑底白字一个失误就可能让人忐忑半天。BrewUI 可以让你在图形界面里完成大部分软件安装和维护操作至少不会因为敲错命令而产生额外挫败感。你在界面里看到“依赖”“缓存”“服务”这些概念天然比在终端里面对大段日志更容易建立直觉。日常要多台机器管理软件环境的开发者。比如你手上有自己的 MacBook还经常需要在公司电脑上装一套类似的开发环境。BrewUI 让你可以直观地看到两台机器各自装了哪些包、版本有什么差异比开两个终端窗口来回敲brew list高效多了。电脑硬盘空间经常告急的普通用户。很多人不肯用命令行也不愿意研究磁盘里到底什么东西占了空间。BrewUI 把“可清理项”直接列出来一键就能清掉一堆旧版本和缓存对磁盘焦虑症患者来说就是解压神器。5.2 不建议使用的人群反过来也有几类人其实不太需要 BrewUI。第一类是已经把 Homebrew 命令掌握得很熟的老手。他们敲命令的速度比打开 GUI 还快而且经常要写脚本进行批量操作GUI 反而会成为效率瓶颈。这类人不是 BrewUI 的目标用户但可以作为工具推荐给身边的新手朋友。第二类是需要高度自定义软件环境的人。如果你经常需要编译定制版本的软件、打各种编译参数甚至自己写 Homebrew 公式那命令行的自由度和灵活性远远不是 GUI 能比的。用 BrewUI 去干这种活等于拿自动挡去跑越野。第三类是极简主义者——就是那种追求“机器上越干净越好能少装一个软件就少装一个”的人。如果你衡量之后觉得一个月就装两三次软件几十条常用命令已经背得滚瓜烂熟那 BrewUI 对你来说确实可有可无。它解决的是“频繁管理”的痛点使用频次不够高的话多一个软件反而成了心理负担。写在最后的一点个人体会文章写到这儿按理说该总结的都总结完了。我个人在这个工具上实际体验下来的结论是它不是一个“炫技”型工具而是一个“减负”型工具。所谓减负不是让大家从此不学命令行而是把那些机械、重复、低认知难度的日常操作解放出来让你把时间和注意力留给真正需要动脑的问题。如果你刚开始接触 Homebrew或者你身边有人在用 Homebrew 但一直对它敬而远之不妨把 BrewUI 推荐给他让他从“敢装软件”开始慢慢理解包管理器的工作原理。从界面回到命令行永远比从命令行硬啃界面要容易得多。最后再分享一个小技巧就算你主力用 BrewUI也别完全丢掉终端。你可以在终端里敲一下brew list --versions看看系统里所有软件的最新版本清单再敲一下brew deps --tree --installed看看依赖树长得什么样。这些“可视化能力”反而是命令行模式下的独特优势两者结合使用比单纯依赖任何一种方式都更舒服。
