Asahi Linux 这次 Linux 7.1 进展报告，最值得看的不是“又多支持了几个硬件”。

更现实的部分是 macOS 27 Golden Gate 开发者 beta。它让一些用户在启动选择器里看不到 Asahi，也可能让 Linux 误判电池故障并紧急关机。

这事容易被误读。它不是 macOS 27 把 Asahi 数据删了，也没有证据显示苹果在针对性封锁 Asahi。报告里更像是在提醒一件老问题：在 Apple Silicon 上跑 Linux，驱动能不能写出来只是一半，另一半是苹果的启动工具、APFS 元数据和固件 ABI 会不会改。

我的判断也放在这里：Asahi 还在向前走，尤其是 M3 和视频解码。但它同时又被 macOS 27 拉回了兼容性追赶。

macOS 27 beta暴露了两类风险：启动看不见，电源会误判

第一类问题在启动链。

Asahi 的启动方式本来就有点“借道”。安装器会创建一个约 2.5GB 的小 APFS 容器，放入足够让苹果启动工具识别为 macOS 的内容，再把 m1n1 当作内核交给苹果 bootloader 启动。

这套方式从 macOS 12 到 macOS 26 基本可用。到了 macOS 27 beta，过去一个被忽略的条件开始生效：APFS 卷需要显式设置“可启动”标记。

此前 Asahi 没设这个标记，也能出现在 Startup Disk 和长按电源键呼出的 boot picker 里。升级到 macOS 27 beta 后，一些用户发现 Asahi 选项消失。

但重点是：分区还在，官方也没有看到数据丢失迹象。新的 Asahi Installer 已经会自动设置这个标记，并提供 “Fix macOS 27 boot picker compatibility” 修复模式。已有安装可以靠这个模式恢复显示。

第二类问题在电源管理。

macOS 27 更新了 SMC 固件接口。电池相关返回值从 32 位变成单字节后，旧的 Linux 驱动可能读错状态，把正常电池判断成故障，再触发紧急关机。Asahi 下游内核 7.0.12 已经做了适配。

这两件事放在一起看，影响很清楚：开发者 beta 不是普通系统更新。它还会更新全局固件。官方也明确不建议在生产机器上安装 macOS 开发者 beta，因为回滚固件往往需要 DFU 恢复整机。

风险macOS 27 beta 的变化用户看到的现象当前处理方式
启动选择器不显示 Asahi开始检查 APFS 可启动标记Asahi 选项消失，容易误以为安装没了新安装器自动设置标记，已有安装可用修复模式
电源管理误判SMC 电池接口返回值变化Linux 可能误判电池故障并紧急关机下游内核 7.0.12 已适配
beta 固件回滚全局固件随 beta 更新出问题后回退成本高官方不建议生产机器安装

对两类人，动作应该很直接。

如果你的 Mac 是主力机，而且已经装了 Asahi，不要为了尝鲜上 macOS 27 开发者 beta。收益有限，排障成本可能很高。

如果你负责实验室、团队测试机或开发机，最好把 macOS beta 和 Asahi 环境拆开管理。至少别把唯一可用的 Apple Silicon Linux 机器放进 beta 固件路径里。

M3进展快，但还没到正式开放安装

报告里积极的一面是 M3。

Asahi 已经在 M3 机器上实现了高质量音频输出、CPU 调频、big.LITTLE 任务调度、SMC 传感器，以及 PCIe、Wi-Fi、蓝牙、NVMe、键盘、触控板等基础硬件支持。m1n1 1.6.0 也加入了更多 M3 支持，包括 SPMI 控制器和 PCIe 初始化。

这说明 M3 支持已经过了早期“摸黑找路”的阶段。

原因不神秘。Apple Silicon 仍然封闭，但苹果没有在每一代都把底层设计推倒重来。音频链路里的 I2S 控制器、NCO 时钟、扬声器和耳机放大芯片变化不大。CPU 调频机制从基础款 M2 以来也基本沿用。

对 Asahi 来说，这很重要。只要硬件模式能复用，很多工作就不必从零开始。Devicetree 补充、已有驱动调整和少量初始化代码，就能覆盖一批新机器。

这和传统 x86 PC 很不一样。x86 Linux 通常有 ACPI、UEFI 和更成熟的厂商生态兜底。Apple Silicon 更像一台高度定制的封闭设备：规律一旦摸清，推进会很快；苹果只要改启动工具或固件接口，维护压力也会马上回来。

但 M3 还不能被写成“已经能正式安装 Asahi”。项目方说得很清楚：距离启用 Asahi Installer 支持仍有工作要做。

所以，对想买 M3 Mac 跑 Linux 的人，我会把建议说得保守一点：如果 Linux 是刚需，M1/M2 仍是更稳的选择；如果你已经有 M3，可以观望安装器开放，而不是把当前进展当成可日用承诺。

方向M3 当前状态现实判断
音频输出已有高质量音频输出复用了较多前代经验
CPU 与调度CPU 调频、big.LITTLE 调度已推进基础性能管理路径更清晰
基础硬件PCIe、Wi-Fi、蓝牙、NVMe、键盘、触控板等已有支持距离可用体验更近
安装器Asahi Installer 尚未开放 M3 支持还不能当作正式可装

视频解码和m1n1，决定的是日用上限

AVD 视频解码是这次报告里更偏长期的一块。

苹果的 AVD 固件不是 RTKit，也不是 EPIC，而是另一套机制。固件和配置数据还打包在 macOS 的 AVD kext 里，不同 SoC 的偏移和参数也不同。

Asahi 选择的路线，是自写一个简化固件。这个固件负责处理中断，也负责写入各版本调校参数。Linux 侧再通过 V4L2 驱动直接编程解码硬件。

这条路不轻松，但方向很干净。它尽量减少对苹果固件黑箱的依赖，也更符合 Linux 上游驱动的长期维护方式。

现在的边界也要讲清楚：目前只有 AVC/H.264 可工作，支持 10-bit、最高 4K，并能配合实现 V4L2 Request API 的软件。VP9、HEVC、AV1 还没完成，也还没有面向用户发布。

这不是炫技问题。浏览器看视频、播放器播放本地文件、视频会议耗电，都和硬解能力相关。没有稳定硬解，笔记本续航和发热就很难接近 macOS 下的体验。

m1n1 1.6.0 也是同一类长期投入。它首次要求 stage 2 构建使用 Rust，并把 GPU 初始化前移到 m1n1。这样做会增加发行版打包成本，但能减少 Linux 内核驱动处理苹果硬件初始化数据的负担。

更现实的价值在上游。GPU 初始化越干净，未来驱动进入主线 Linux 的阻力就越小。对 Asahi 这种项目来说，能不能上游化，往往决定后期维护是不是一直靠少数人背着走。

接下来要看的变量不多，三件事就够了。

观察点为什么重要判断条件
macOS 27 正式版行为决定 beta 暴露的问题是否变成长期兼容成本启动标记和 SMC 接口是否继续保持当前逻辑
M3 Installer 支持决定 M3 是否从开发进展进入用户可安装阶段官方安装器何时开放，基础体验是否稳定
AVD 解码扩展决定视频、续航和发热体验上限H.264 之外，HEVC、VP9、AV1 何时可用

如果这三项都顺，Asahi 的主线就是继续推进。若苹果固件和启动链频繁变化，社区就会被迫拿更多时间修“昨天还能用”的东西。

这也是 Apple Silicon Linux 的现实约束：山不让路，人只能修栈道。Asahi 能走多远，不只看社区写驱动的能力，也看脚下这条路会不会突然改线。