Apple 把 MacBook 变成了 Linux 开发机：WWDC 26 被忽略的重磅发布
- 引言：所有人都错过的那条新闻
- 两年铺垫：从 Containerization 框架到 container 1.0
- 上手实操：今天就能用起来
- 需要知道的坑
- 这对你的工作流意味着什么
- Apple 到底在下一盘什么棋
引言：所有人都错过的那条新闻
WWDC 26 的 Keynote 上，Apple Intelligence 拿了最长的时段，Vision Pro 拿了最炫的 Demo，新的设计语言拿走了所有营销预算。
而整个大会对开发者来说最有分量的发布，被埋在 Session 389 里——一个叫 Michael 的工程师，在一间小房间里，讲了一整场连标题卡片都没有的演讲。
这个发布叫 Container Machine。它是一个原生运行在 macOS 26 上的 Linux 环境：启动时间不到一秒，自动挂载你的家目录，使用你 Mac 上的用户名，支持任何 OCI 兼容镜像——也就是你在 Docker Hub 上拉过的所有东西。它免费、开源、随操作系统内置。
如果你是一名开发者，曾经为了在 Mac 上测试服务器代码而维护一台 Linux 虚拟机，或者花钱买过 Docker Desktop，或者被 Orbstack 的授权条款折腾过，又或者桌上始终放着一台破旧的 Ubuntu 笔记本专门用来”跑 Linux 的活”——Apple 刚刚把所有这些基础设施变得多余了。
你的 Mac，现在是一台一等公民的 Linux 开发机。不是”一台跑着虚拟机的 Mac”，而是一台 Linux 开发机。缝隙几乎消失了。
两年铺垫：从 Containerization 框架到 container 1.0
要理解 Container Machine，得先看它脚下的一年功夫。
第一步：WWDC 25 的 Containerization 框架
2025 年 6 月，Apple 同时开源了两样东西：一个叫 Containerization 的 Swift 框架，和一个叫 container 的 CLI 工具。
Containerization 是一个底层框架——负责镜像管理、容器执行、网络、存储，以及一套完全用 Swift 编写的 Linux init 系统。container CLI 是面向开发者的封装：一个长得像 Docker 的命令行工具，可以拉取 OCI 镜像、运行它们、管理它们。
让这一切成立的关键架构决策是：每个容器一台轻量虚拟机。
Docker Desktop 和 Podman 是另一条路：它们启动一台大型 Linux 虚拟机，然后在里面跑你所有的容器。容器共享内核、共享网络接口（这就是为什么你必须用 -p 8080:8080 做端口映射）、共享文件系统挂载面。
Apple 的 container 工具则为每个容器启动一台全新的轻量 Linux VM：
- 启动时间亚秒级
- 每个容器拥有独立的 IP 地址——不需要端口映射，直接访问容器的 IP 就行
- 每个容器只挂载你显式共享的目录
- 如果你停止了所有容器，你的机器上就不会运行任何 Linux——没有后台守护进程吃资源
安全上的影响是实打实的。在 Docker Desktop 模型里，如果一个容器被攻破，共享的 VM 内核就是其他所有容器的爆炸半径。在 Apple 模型里，每个容器独占一台 VM，爆炸半径就是一个容器。
隐私上的影响同样真实。在 Docker Desktop 模型里，你把宿主机目录绑定进容器时，这个目录会先挂载到共享 VM 里，只要允许，其他容器都能看到它。在 Apple 模型里，目录直接挂进目标容器的 VM，不会进入任何其他地方。
这套架构的核心叫 vminitd——一个静态链接的 Swift 二进制，在每个轻量 VM 里以 PID 1 的身份运行。没有 libc、没有核心工具、没有动态库，用 Swift 的 Static Linux SDK 对着 musl 编译。每个容器 VM 的攻击面，是能承载你工作负载的最小的 Linux 用户态。
这是 2025 年 6 月的事，是地基。
第二步：container 1.0，2026 年 6 月 11 日
一年后，经历了从 0.1（2025 年 6 月）到 0.8（2026 年 2 月）共二十个小版本，Apple 在 2026 年 6 月初发布了 container 1.0。生产就绪，标准 OCI 镜像兼容性验证完毕，Bug 数量降到个位数，性能基准在大多数指标上和 Docker Desktop、Orbstack 持平，内存吞吐上领先。
如果你只看新闻到这一步，你会以为 Apple 造了一个更快的 Docker。并没有。他们造的是真正那个发布的地基。
第三步：WWDC 26 的 Container Machine
这才是改变开发者体验数学的那部分。
一个容器机（container machine）是一个被赋予了两种它本不该有的属性的容器：持久化，和深度宿主机集成。Apple 在 Session 里的表述很准确：它”像容器一样快而轻量，像虚拟机一样持久，加上宿主机集成，容器机用起来就像 macOS 的原生功能”。
拆开看这些词背后的含义：
持久化意味着容器机有状态。 你周二在里面 apt install 的工具，周三还在。你周三在容器家目录里写的脚本，周四还在。这不同于普通容器——普通容器里，除了显式挂载的卷，其他东西一重启就蒸发。
自动用户映射。 容器机里的用户名和你 Mac 上的用户名一致。你的 Mac 账号叫 mike，你在容器机里登录也是 mike。UID/GID 一致，权限模型跨宿主机/访客边界直接工作。
自动家目录共享。 你的 Mac 家目录默认挂载进容器机——在同一路径下。你在 Mac 的 ~/projects/web-server 里编辑的文件，就是容器机里 cargo build 读到的那个文件。没有同步、没有 docker cp、没有卷挂载声明。
工作目录继承。 你在 Mac 终端里位于 ~/projects/web-server，敲下 container machine run，进入的就是 Linux 环境里的同一路径。”等等，我现在在容器里的哪里？”这种认知开销消失了。
真正的 init 系统。 systemd 能工作。你可以把 postgres、redis、nginx 跑成正经的系统服务，而不是被包裹的进程。你最终部署到的 Linux 服务器栈，本地模拟时行为完全一致。
如果你用过 Windows Subsystem for Linux 2，这个对比很贴切。The Register 的评价是”一个 WSL 式的东西”，这个说法公允。执行模型和安全模型不同，但开发者体验的目标是一样的。
上手实操：今天就能用起来
下面是从零开始用 Container Machine 的全部命令。
安装
brew install container
就这一条。不想走 Homebrew 的话，也可以直接去 apple/container 的 releases 页面 拿安装包。container 和 container machine 是同一个 CLI 的两个子命令，Container Machine 不需要单独安装——macOS 26 上随 container 1.0 一起提供。
创建你的第一个容器机
先用最轻量的基础镜像 Alpine 验证一切正常：
container machine create \
--name dev \
--default \
alpine:latest
这条命令做三件事：从 Docker Hub 拉取 alpine:latest 的 OCI 镜像；基于它创建一个名为 dev 的容器机；--default 把 dev 设为默认机器，之后的命令就不用每次都指定。
验证一下：
container machine list
你会看到你的机器、它的 IP 地址、CPU 分配（默认 7 核）和内存分配（默认是你系统内存的一半）。
跑一条一次性命令
container machine run uname -a
这行会打印 Linux ... GNU/Linux——证明你在 Linux 环境里。对比一下在 Mac 终端直接跑 uname -a，打印的是 Darwin。两个不同的内核，一套工作流。
进入交互式 Shell
container machine run
不带任何参数。你现在就在 Linux 里了，坐在你启动时所在的同一个工作目录。你的 Mac 家目录在，你的用户名一样，你的文件都在。
构建一台真正的开发机
Alpine 做概念验证没问题，真干活还是想要一个更完整的发行版。下面这个 Dockerfile 给你一个可用的 Ubuntu 24.04 开发环境：
FROM ubuntu:24.04
RUN apt-get update && apt-get install -y \
build-essential \
git \
curl \
wget \
vim \
htop \
systemd \
&& rm -rf /var/lib/apt/lists/*
# 真正的 init，让 systemd 管理的服务能工作
CMD ["/sbin/init"]
用 container 工具构建它：
container build -t local/ubuntu-dev .
再把它变成一个持久化的容器机：
container machine create \
--name ubuntu-dev \
--default \
local/ubuntu-dev
这就是你常驻的 Linux 机器。从此以后，你装进去的任何东西——nodejs、postgres、redis、语言工具链、自定义工具——重启后都在。
用 SSH 连上你的编辑器
开发者社区反馈最多的坑是：在 Mac 侧编辑、Linux 侧运行时，VS Code 的热重载和调试断点不干净。文件系统桥是可靠的，但文件监听事件不会传播。
解决办法在 Apple 自己的文档里，两分钟搞定：不要通过宿主机挂载编辑，改成通过 SSH 连接编辑器。
# 获取 IP
container machine list
# 直接 SSH 进去
ssh <your-username>@<container-machine-ip>
然后在 VS Code 里装 Remote-SSH 插件，指向这个 IP。现在你是在容器机的网络内编辑文件。热重载正常了，断点正常了，文件监听正常了。
这一个动作，把 Container Machine 从”适合测试”变成了”适合日常使用”。
跑一套真实的服务栈
这是让整套架构物有所值的工作流。你可以在一个容器机里跑 Postgres + Redis + 你的应用，用 systemd 管理服务，然后从 Mac 的浏览器直接访问。
在容器机内部：
sudo apt-get install -y postgresql redis-server
sudo systemctl enable --now postgresql redis-server
这行 systemctl enable --now 就是魔法所在。Container Machine 有真正的 init 系统，所以 systemctl 确实干它该干的事。Postgres 起来了，Redis 起来了，容器机重启后它们还活着，行为就像真实 Linux 服务器上的服务。
从 container machine list 拿到 IP 后，打开 Mac 上的 Safari，访问 http://<ip>:<port>，你就在访问一套远程 Linux 服务器式的服务栈了——只不过它一秒启动、共享你的家目录。
多发行版并行
你不局限于一台容器机。Ubuntu、Alpine、Fedora 可以同时跑：
container machine create --name ubuntu-dev local/ubuntu-dev
container machine create --name alpine-test alpine:latest
container machine create --name fedora-check fedora:40
指定机器执行命令：
container machine run --machine alpine-test uname -a
这就是跨发行版测试变得轻松的那部分架构。如果你的项目需要在 Ubuntu 和 Alpine 上都跑通，你在 Ubuntu 机器上编译，立刻在 Alpine 机器上测试，全程不用离开终端。
需要知道的坑
有三件事，没提前看到的话一定会绊倒你。
内存是粘滞的
容器机默认占用你系统内存的一半，空闲时不会还给 macOS。如果构建过程内存飙升，这部分内存会一直被占用，直到你重启容器机。这是 Orbstack 最受好评的功能之一（动态内存释放），Apple 还没跟上。如果你在 16GB 的 Mac 上创建三台容器机，那就是 8GB 的分配问题。建议在创建时用 --memory 给每台机器设明确的内存上限：
container machine create --memory 4g --name dev local/ubuntu-dev
还没有 GPU 和 USB 透传
如果你的工作流涉及 CUDA、GPU 加速的 ML 推理，或者需要在 Linux 里访问 USB 设备，Container Machine 目前还不适合你。这两项都有开放的 issue，盯着 GitHub 看进展。
家目录默认读写挂载是安全暴露
把整个 Mac 家目录挂进 Linux 很方便，但代价是：Linux 里跑的任何东西——包括一个恶意的 npm 包或受污染的镜像——都能读到你的 SSH 密钥、~/.aws/credentials、你的一切。可以用 --home-mount readonly 把挂载变成只读，或者用 --home-mount none 完全关闭。任何你要跑不可信代码的容器机，都建议这么做。目前还没有按文件夹的挂载粒度。
Docker Compose 缺位
如果你看过 2026 年初的社区讨论，会知道 Compose 是 container 0.x 唯一明显的缺口。到 macOS 26 的 container 1.0，这个缺口还在。Apple 没有提供 Compose 等价物。社区在填补——至少有三个第三方封装在活跃开发中——但还没有一个达到 Docker Compose 的成熟度。
目前的务实做法是：多服务负载就跑成单容器机 + systemd 管理服务，这个方案很干净。如果你真的需要每个服务一台机器的 Compose 式编排，可以写个 shell 脚本，每个服务跑一条 container machine create，再用 IP 把它们串起来。
这个问题会被解决的，是几个月的事，不是几年。
这对你的工作流意味着什么
过去十年，”在 Mac 上为 Linux 开发”的工作流大致是：装 Docker Desktop、忍受它的内存占用和授权费、写 docker-compose.yml、在共享 VM 里跑服务、挂载需要的卷、祈祷文件监听能传播、容忍各种缝隙。
Container Machine 把这条工作流压缩成三条命令和一个 Dockerfile。缝隙变小了。”我是在 macOS 还是 Linux”的认知开销消失了——你的终端看起来一样、用户名一样、家目录一样、编辑器一直开着。你敲下 container machine run，shell 底下的内核就变了。
按我的统计，实际的效率提升：
- 不再有 Docker Desktop 的开销，回收 2-4GB 基础内存
- 不再有”文件去哪了”——宿主机目录就是容器目录
- 本地开发不再需要端口映射，每台机器有自己的 IP
- 用真正的 systemd 做本地服务级测试，测的就是要部署的
- 不出终端就能做跨发行版测试
- 通过 SSH 做编辑器侧热重载（一次性配置，之后一直生效）
- 亚秒级冷启动意味着你可以随手
container machine create做一次性实验
如果你往 Linux 服务器上部署任何代码——除非你全职写 iOS 应用，否则大概率是的——你在 2026 年 6 月 8 日的工作流，不该是 2026 年 6 月 25 日的工作流。工具变了，该动了。
Apple 到底在下一盘什么棋
退一步看这些命令。
Apple 花了两年时间构建开发者基础设施，只做一件事：让 Mac 成为做 Linux 服务器端开发最高产的地方。他们本不必做这些。可以把容器留给 Docker，可以给 Orbstack 套个漂亮的壳然后说搞定。他们自己动手了，用 Swift 写，为 Apple Silicon 优化，安全模型超过现有玩家。
他们在争取的，是那批为了正经服务器端工作而流失回 Linux 笔记本的开发者。Framework 笔记本那拨人，”我需要真 Linux 跑 CI”那拨人，”Docker Desktop 太重”那拨人。Apple 想让这些开发者留在 Mac 上，为此愿意花两个 WWDC 的工程资本。
而且这招正在奏效。性能基准有竞争力，架构比替代品更安全，集成比 Windows 上的 WSL 更紧密，价格是零。
你桌上的 MacBook，现在是一台一等公民的 Linux 开发机。不是在营销意义上，而是在字面意义上——你可以从这台设备上交付生产级的 Linux 服务器软件，不需要第二台机器。
这就是 WWDC 26 真正改变的东西。这是大多数报道漏掉的东西。这是一个 brew install 就能解锁的生产力。
如果你团队里还有工程师在维护一台单独的 Linux 机器专门”跑服务器那摊事”，或者还在给 Docker Desktop 付费——把这套搭建命令发给他们，这就是全部的上手曲线。