2026 年 9 月 13 日，Homebrew 发布 7.0.0。这个 macOS 上安装量最大的第三方包管理器在这个大版本里做了两件事：把官方图形界面 BrewUI 推到正式发布状态，同时重写了安全模型，内置漏洞数据库 brew vulns。与此同时，Intel Mac 被移到 Tier 3 支持层级，2027 年 9 月之后不再有预编译包。
对一个 2016 年就躺在 GitHub 上（brew 仓库创建于 2016 年 3 月）的工具来说，官方 GUI 是一件迟到很久的事。过去十年里，给 Homebrew 套图形界面的第三方项目出现过一大批，Cakebrew、Applite、Cork 各自维护着一批用户，但没有一个来自官方。这次不同：BrewUI 挂着 Homebrew 组织的名号，代码在 Homebrew/BrewUI 仓库，README 里写着「Homebrew's official macOS GUI」，随 7.0.0 一同宣布 fully released。
BrewUI 怎么做事：透明优先于便捷
BrewUI 用 Swift 6.0 的严格并发模式写成，SwiftUI 界面，要求 macOS Tahoe 26 及以上，安装命令是：
brew install --cask homebrew-app
界面上手没有门槛：左侧五个入口（Installed、Upgrades、Discover、Doctor、Configuration），Installed 标签列出所有已安装的 formula 和 cask，带搜索框和 All/Formulae/Casks 三个筛选片；右侧详情栏显示版本、来源 tap、依赖关系。这些信息来自 brew CLI 和 formulae.brew.sh 的 JSON API，GUI 本身不持有独立的包数据库。
值得展开的是它执行命令的方式。BrewUI 所有 Homebrew 调用（包括应用自升级）都通过 /bin/zsh 启动，并带上 --no-rcs --no-global-rcs，禁用用户和系统的 shell 启动文件；传给 Homebrew 的 PATH 只包含定位到的 brew 可执行文件所在目录，再加 /usr/bin:/bin。你登录 shell 里的别名、导出的变量、自定义 PATH，对 BrewUI 里的 Homebrew 全部不可见。
这个设计会让一部分用户意外：在 ~/.zshrc 里设置的 HOMEBREW_* 环境变量，在 BrewUI 里不生效。官方给出的替代方案是 brew.env 文件，分三个作用域：用户级 ~/.homebrew/brew.env、安装级 <prefix>/etc/homebrew/brew.env、系统级 /etc/homebrew/brew.env，写 NAME=value 字面量，不带 export，不允许 shell 展开。用户设置默认覆盖安装级，安装级覆盖系统级，除非在系统文件里设 HOMEBREW_SYSTEM_ENV_TAKES_PRIORITY=1。
动机不难理解：环境变量注入是 shell 启动文件里最容易藏东西的地方。一个被篡改的 ~/.zshrc 可以给任何应用注入恶意 PATH 或 DYLD_* 变量，BrewUI 直接把这条路堵死了。它甚至主动清掉 shell 启动文件的输出，防止 banner 文本混进 Homebrew 的报告和控制台。
界面右侧详情栏里有一个「Terminal command」区块，直接显示当前操作对应的终端命令，比如卸载 1Password 时显示 brew uninstall --cask 1password，旁边给复制按钮。GUI 的每个动作都对应一条可见的 brew 命令，这是这个应用最有意思的设计决定：它不打算替代你对包管理的理解，只替代你敲命令的手。
brew vulns：补齐包管理器最后一块安全短板
7.0.0 里对安全团队更有分量的更新是漏洞检查成为内置能力。Homebrew 建了自己的 advisory database，按公式版本和 revision 记录漏洞，包括回移（backport）的修复，查询 OSV.dev，不需要额外装 tap 或 gem：
brew vulns这条命令扫描已安装的 formula 并报告漏洞，--severity=high 过滤高危项，--deps 连依赖一起查，--brewfile 按 Brewfile 查，--fix-available / --no-fix-available 按是否有修复排序，--fix-type 区分「升级版本可修」和「补丁回移可修」。配套地，Homebrew 识别带 resolves 注解的安全补丁，避免对已经包含修复的包重复报警。
数据层面，advisory findings 发布在 formula API 和一份可下载的 advisory index 里，OSV 格式的记录以 CC0 协议开放，安全团队可以把 Homebrew 的漏洞数据接进自己的工具链。Homebrew 还在软件物料清单（SBOM）里加上了上游包标识符，让外部工具能把源码归档连回 PyPI、npm、Cargo 这些注册表，而不是只认 Homebrew 的 formula 名。
在 brew vulns 出现之前，一个用 Homebrew 管理开发依赖的 Mac，漏洞面基本处于无工具可查的状态：npm 有 npm audit，Cargo 有 cargo audit，Python 生态有 pip-audit，而 brew 什么都不带。系统里装着几十个 CLI 工具和库，哪个版本有 CVE、修复在哪个 revision 里，只有自己去查 NVD。现在这条链路被补上了，而且直接进主程序，不需要安全团队额外维护扫描器。
7.0.0 本身也跟着一批安全修复：高危漏洞 GHSA-rg9r-ppxp-87hm（6.0.12 修复，未签名的 cask 卸载元数据可能以 sudo 执行命令）之外，两个中危涉及沙箱逃逸和安装器 Git 配置注入，另有一批低危修复覆盖 SSRF、重定向头泄漏、tap 限制绕过等。
沙箱与性能：安装管线的重写
7.0.0 的沙箱升级把 formula 和 cask 操作放进沙箱执行，减少任意 Ruby 执行面。迁移仍在进行中的部分：依赖下载逐步挪进独立的 fetch 阶段，迁移后的包在下载阶段有网络和可写缓存，进入 install 阶段后断网、缓存只读。默认情况下，沙箱内的构建读取不到用户主目录，包构建过程接触不到无关的个人文件。官方文档同时把边界讲清楚：tap 信任仍是防恶意 cask 的主要防线，沙箱主要限制意外破坏，它不能让不可信软件变得安全可运行——应用依然以你的用户权限执行，厂商的 .pkg 安装器运行在沙箱之外，可能需要 sudo。
Linux 侧的变化是从 Bubblewrap 换到 Landlock：不再需要依赖和提权的 Docker 权限（Bubblewrap 的配置曾带来不少问题），内核不支持 Landlock 的系统回退到 6.0 之前的无沙箱配置，brew doctor 会给出建议级报告。
性能方面，7.0.0 把并发铺到了整条安装管线：brew install、reinstall、upgrade 重叠包的准备和下载阶段，Brewfile 批量安装共享同一次安装工作；brew fetch 直接从 API 元数据读下载信息，不必先加载完整包定义再找 URL 和校验和；brew cleanup 避免重复扫描缓存；解析过的 API 数据在热运行中复用，同时每次加载都验签名，砍掉重复命令的准备时间但不放弃真实性校验。
Intel Mac 的退场时刻表
7.0.0 的公告里最冷的一条是平台支持变化：macOS 10.15 及更早版本停止支持；Intel Mac 降到 Tier 3——继续运行但没有项目支持、没有新的预编译 bottle。时间线写得很明确：Intel macOS 11 及以上版本 2027 年 9 月 1 日前还能用，之后 Homebrew 停止运行；Apple Silicon 上的 macOS 11 同样 2027 年 9 月到期。
官方给的理由没有留余地：Apple 已从 macOS 27 Golden Gate 中移除 Intel x86_64 支持，GitHub Actions 将在 2027 年秋季退役 Intel macOS runner。公告原话是，如果 Apple 和微软的 GitHub 这两个全球最大的科技公司都无法继续支持 macOS Intel x86_64，「遗憾的是 Homebrew 也不能」，并建议 Intel 用户考虑迁移到仍支持 Intel 的 MacPorts。
这个决定对开发环境的影响是实打实的：Tier 3 意味着没有新 bottle，源码编译将成为 Intel Mac 上的常规操作，构建时间和依赖失败率都会上升。对还在 Intel 机器上跑生产工具链的人来说，2027 年 9 月是迁移的硬截止。
对 macOS 用户，升级路径就是一条 brew update。如果你在 Tahoe 26 以上，再加一条 brew install --cask homebrew-app，十年没有图形界面的 Homebrew 就有窗口了。只是要记得：你在 ~/.zshrc 里为 brew 设置的环境变量，在这个新窗口里不作数，得搬到 ~/.homebrew/brew.env 去。