Homebrew 7.0 发布：命令行工具第一次长出 GUI，Intel Mac 进入一年倒计时
TL;DR 速览
- BrewUI：Homebrew 17 年来第一个官方 GUI，但每个操作都会显示它执行的真实brew 命令
- brew vulns：内置漏洞扫描，基于OSV.dev，不用装额外 tap，可进 CI
- Deadline：2027-09-01 起 Homebrew 彻底停止在 Intel Mac 上运行
- 安全：本次修复8 个公告，含一个可借 sudo 执行命令的高危项
Homebrew 发布 7.0 了。这个包管理器过去十几年的更新大多是“支持了新的 macOS 版本”“某个 formula 改了依赖”这类例行内容，7.0 是少见的一次结构性变化——GUI、漏洞扫描、沙箱实现、时间表，四件事同时落地。
按对新用户、对安全团队、对 Intel Mac 用户的顺序说。
一、BrewUI：17 年来第一次有官方 GUI
Homebrew 从 2009 年到现在一直是纯命令行工具，社区里的图形界面都是第三方的。7.0 第一次给了官方原生 GUI：
brewinstallhomebrew-app装上之后，包浏览、搜索、已安装版本信息都在一个窗口里搞定。要求macOS Tahoe 26 以上。
这个 GUI 里有一个设计细节我认为值得单独说：每一个图形操作，都会显示它底层实际执行的 brew 命令。
不是把终端藏起来，而是把 GUI 和命令对应起来。这个选择很聪明——它的作用是“教学”而不是“替代”：用户点了几次按钮，就自然学会了对应的命令行写法，最终还是回到终端里干活。
对老用户来说，GUI 的实际价值有限；对刚接触 macOS 开发环境的人来说，这是门槛最低的入口。
二、brew vulns：macOS 开发机的漏洞门禁
这是本次更新里我认为对团队最有实际价值的一项。
新增内置漏洞扫描命令，数据源是OSV.dev加上 Homebrew 自己的 advisory database。关键点是不需要再装额外的 tap 或 gem——以前要做这件事，得自己搭一套第三方方案。
基本用法：
brew vulns# 扫描全部已安装包brew vulns--severity=high# 只看高危它支持的几个细节比较实用：
- 可检查依赖——不只是你直接装的包，还包括依赖树里的问题；
- 能区分“有修复可用”与“暂无修复”——这个区分很重要，前者可以行动，后者只能等待或替换，混在一起会让报告失去可用性；
- 配套开放了Homebrew/advisory-database，OSV 格式、CC0 协议、可自由复用；
- 公告数据进了 formula API，并提供可下载索引；
- SBOM 里加上了上游包标识（PyPI / npm / Cargo 的对应关系）。
为什么这件事意义大：Linux 发行版早就有发行版级的安全公告机制（Debian Security Tracker、Red Hat CVE 页），Homebrew 此前是完全空白——你装了什么、哪个版本带哪个 CVE，全靠自己查。现在可以在 CI 里跑一次针对 Brewfile 的检查，给 macOS 开发机构建一道漏洞门禁。
具体怎么做：把brew vulns挂进 CI，对 Brewfile 做一次扫描，高危项非零则阻断构建。这一步的成本很低，但覆盖了一个长期没人管的盲区。
三、沙箱换了实现，理由很务实
Linux 侧，用内核原生的 Landlock 替换了 6.0.0 引入的 Bubblewrap（支持 Linux 6.1+ / Landlock ABI 2）。
选择 Landlock 的理由是工程性的：零依赖、不需要提权 Docker 权限。Bubblewrap 落地时的摩擦主要就来自这两点——它需要额外的依赖，在容器化环境里还牵扯权限。
降级策略做得很干净：内核不支持 Landlock 时，Homebrew 仍可正常运行，只是退回旧的无沙箱配置，brew doctor给出 advisory 提示而不是报错。这个处理方式值得学——安全机制的新增强化不应该让用户的工具直接坏掉。
macOS 侧，做了两处收紧：默认阻断沙箱内读取用户主目录；把依赖下载迁到独立的 fetch 阶段——下载时有网络和可写缓存，进入 install 阶段就断网、缓存只读。这个拆分把“需要联网的环节”和“执行代码的环节”分开了，是沙箱设计的标准思路。
四、最重磅的时间表：Intel Mac 开始倒数
这条是本次更新里影响面最大的。
| 对象 | 变化 |
|---|---|
| Intel macOS 11+ | 降至Tier 3 |
| Tier 3 的实际影响 | 现有 bottles 保留，但更新过的 formula 可能要源码编译，且会越来越频繁 |
| Intel Mac 整体 | 2027 年 9 月 1 日起，Homebrew 彻底停止在 Intel 上运行 |
| macOS 10.15 Catalina 及更早 | 立即移除支持 |
| macOS Sonoma 14 | 降至 Tier 3 |
| 官方 .pkg 安装器 | 仅支持 Apple Silicon，且要求 Sequoia 15+ |
注意措辞是“停止运行”而不是“停止支持”。这两个词差别很大：停止支持意味着还能用但不再修 bug；停止运行意味着这个软件根本跑不起来。对还在用 Intel Mac 做开发机的人来说，2027 年 9 月 1 日之后brew命令会直接失效。
官方这次罕见地给了一条后路：Intel 用户可以转向 MacPorts。
而原因不在 Homebrew 自己——Apple 已在 macOS 27 Golden Gate 中砍掉 Intel x86_64；GitHub Actions 也计划在 2027 年秋退役 Intel macOS runner。官方的原话很直白：如果 Apple 和 GitHub 这两家世界上最大的科技公司都无法继续支持 macOS Intel x86_64，很遗憾 Homebrew 也做不到。
判断很简单：还在用 Intel Mac 做开发机的团队，现在迁移的成本远低于一年后被动迁移。现在迁移是计划内的工程任务，2027 年迁移是计划外的救火。
五、被忽略但影响 tap 维护者的改动：去 Ruby 化
formula 的post_install钩子和 cask 的各类 flight Ruby 块被弃用，改为声明式 steps。
这个改动的动机是安全，不是整洁：显式操作与路径可以被验证、可以沙箱化、可以经签名 API 下发，而不是“装包的时候执行任意 Ruby 代码”。
执行力度也不含糊：官方 tap 已直接拒绝旧钩子；第三方 tap 宽限到 2027 年 12 月。
如果你维护自己的 tap，这是个明确的迁移信号——宽限期三年，但旧写法已经不会被官方接受了。
六、安全修复要点与一个彩蛋
本次修复8 个安全公告，其中两个值得单独记：
- 一个高危项：未签名 cask 的删除元数据可能借
sudo执行命令。官方的处理方式是把脆弱代码全部删除，不是打补丁——这个选择比修补更彻底，也说明这段代码的问题在结构上。 - 一个中危项：沙箱逃逸——恶意 cask 可以经由 LaunchServices 在安装沙箱之外执行代码。
彩蛋：发布时，Homebrew/brew 仓库处于零 open issue状态。一个纯志愿项目能做到这一点，工程纪律确实值得说一句。
我的判断
我的读法是：7.0 真正的主角不是 GUI，是“可验证性”这个主题的三次落地。
brew vulns让已安装的软件可以被检查；去 Ruby 化让安装过程可以被审计（声明式步骤、签名 API 下发，而不是执行任意脚本）；沙箱从 Bubblewrap 换成 Landlock，让权限模型更清晰、更少依赖。三件事指向同一个方向：把“看不见的执行”变成“能验证的动作”。
GUI 反而是这次最不重要的部分——虽然它是最容易被媒体拿来当标题的部分。值得注意的是它的设计取向：显示底层命令。这个取向跟上面三件事是一致的：不隐藏机制，而是把机制暴露出来。
对团队的实际动作我给两条：
第一，把brew vulns挂进 CI。这是这次更新里投入产出比最高的一项——几行配置，补上一个之前完全不存在的检查环节。做 macOS 开发机的团队，尤其值得。
第二，Intel Mac 的迁移排期要提上日程了。2027 年 9 月 1 日看起来还远，但开发机更换涉及预算、数据迁移、环境重建、CI runner 更替，实际周期通常比预想长。Apple 砍 x86_64、GitHub 退 Intel runner、Homebrew 停运行——三个信号指向同一个方向，这已经不是“要不要迁”的问题，是“什么时候迁”的问题。
对个人开发者，最实际的一条：去跑一次brew vulns。大概率你会看到几个自己没注意过的包带着已知漏洞——而这正是这条命令存在的意义。
