Mac 上跑 Linux 容器,为什么 Apple 选择给每个容器一台轻量 VM?

这几天 GitHub Trending 很热闹。

榜单前面又是 Agent Skills、AI 编程规则、系统提示词、Claude 教程。

这些项目都有价值。

但今天我想换一个更底层的项目：apple/container。

项目地址：https://github.com/apple/container

它做的事情很明确：

在 Mac 上创建和运行 Linux 容器。

但重点不是“又一个容器命令行工具”。

真正值得看的，是它选择了一个和很多人习惯不太一样的模型：

每个容器都运行在自己的轻量虚拟机里。

Mac 上跑容器，问题一直不简单

在 Linux 服务器上跑容器，很多人已经习惯了。

进程、namespace、cgroup、镜像、网络，都是一套系统内的东西。

但开发者在 Mac 上跑 Linux 容器时，中间多了一层差异。

宿主机是 macOS。

容器里要跑 Linux 用户态。

构建出来的镜像还要能交给 CI、服务器、镜像仓库和别的容器运行时继续使用。

所以 Mac 上的容器工具，本质上一直在处理一个问题：

怎样让开发者觉得自己在本机直接跑容器，同时又不把 Linux 和 macOS 的差异暴露得太难用。

apple/container 的切口就在这里。

它用 Swift 写，面向 Apple silicon 优化，消费和产出 OCI 兼容镜像。

也就是说，你可以从标准镜像仓库拉镜像，也可以把自己构建的镜像推回仓库，让它在其他 OCI 兼容环境里继续运行。

这让它不是一个封闭玩具。

它仍然站在容器生态的标准接口上。

每个容器一台 VM，换来的是什么

很多 Mac 容器方案会先启动一台 Linux VM，再把多个容器放进去。

这样理解很直观：

Mac 负责桌面和开发环境。

Linux VM 负责真正跑容器。

但 Apple 这个项目的技术文档里说得很清楚，它采用的是另一种方式：

每创建一个容器，就为这个容器运行一台轻量 VM。

这个选择会立刻带来三个问题。

第一，会不会更慢？

第二，会不会更占内存？

第三，为什么要这么做？

项目自己的解释是，这种方式让每个容器获得接近完整 VM 的隔离属性，同时用更小的一组核心工具和动态库降低资源占用与攻击面。

换句话说，它不是为了把容器变成传统大虚拟机。

它是在试图把“VM 级隔离”和“容器级启动体验”放在同一个模型里。

这个模型对开发者有什么意义

对普通开发者来说，最直接的意义不是概念，而是边界更清楚。

一个容器就是一个更独立的运行单元。

共享宿主机文件时，只挂载当前容器真正需要的数据。

如果所有容器都在同一台共享 Linux VM 里，宿主数据往往要先进入那台 VM，再由 VM 内部选择性挂给容器。

Apple 文档把这点归到 privacy。

我觉得更适合翻译成开发者能立刻理解的话：

少把不需要的宿主机目录暴露给一个公共中转层。

对团队开发环境来说，这个边界很有价值。

比如你在 Mac 上同时跑三个东西：

一个测试数据库。

一个临时构建环境。

一个会访问本地源码目录的服务。

如果它们都在更明确的 VM 边界里，排查“谁看到了什么、谁挂载了什么、谁占了多少资源”会更容易。

这不代表它自动比所有方案都安全。

但它把隔离模型放到了一个更容易解释的位置。

它不是只会 run

container 的 README 和教程里给出的路径很完整。

安装后先启动系统服务：

container system start

如果还没有 Linux kernel，它会提示安装推荐默认内核。

然后你可以列出容器：

container list --all

也可以用 Dockerfile 构建镜像：

container build --tag web-test --file Dockerfile .

再运行一个容器：

container run --name my-web-server --detach --rm web-test

这些命令看起来很熟悉。

熟悉很重要。

因为一个新的容器工具如果必须让开发者重学全部操作，就很难进入真实工作流。

更有意思的是，它支持多架构构建。

比如给同一个镜像同时构建 arm64 和 amd64 版本。

在 Apple silicon Mac 上，这点很现实。

你本机是 arm64。

线上服务器、客户环境、历史镜像却可能仍然有 x86-64。

工具如果不能处理这个差异，本地调试和上线环境之间就会一直有缝。

适合先怎么试

不要一上来就拿它替换整个团队的容器工作流。

更合理的方式，是选一个很小但真实的服务。

比如一个 Python 静态页面服务。

一个内部 API mock。

一个需要本地数据库的测试项目。

先验证五件事。

第一，安装条件是否满足。

它要求 Apple silicon Mac，并且当前文档写的是支持 macOS 26。

如果团队里还有 Intel Mac，或者系统版本不统一，这就是第一道门槛。

第二，已有 Dockerfile 能不能顺利 build。

如果镜像构建脚本里依赖很多本地路径、平台假设或特殊缓存，要先看迁移成本。

第三，容器启动、停止、日志、exec、inspect 是否符合你日常调试习惯。

命令熟悉不等于所有细节都一样。

第四，卷挂载和端口转发是否满足本地开发。

官方 how-to 里已经有 --volume、--mount、--publish 和访问宿主服务的例子。

这些才是开发者每天会撞到的地方。

第五，多架构镜像是否真的解决你的问题。

如果你本地只做 arm64，服务器也是 arm64，收益可能没那么明显。

如果你经常在 Apple silicon 上构建要发到 x86-64 环境的镜像，多架构支持就值得单独验证。

它现在的边界也要看清

这个项目不是“所有 Mac 容器问题的最终答案”。

README 写得很直接：

项目仍在 active development。

在 1.0.0 之前，小版本发布可能包含 breaking changes。

另外，它依赖 macOS 26 的虚拟化和网络能力。

这意味着它更像一个面向未来 macOS 容器模型的项目，而不是今天所有团队都能无痛迁移的通用工具。

还有一个现实问题：

如果你团队已经深度依赖现有 Docker Desktop、Colima、OrbStack 或 CI 里的固定脚本，迁移价值必须具体计算。

container 最值得验证的，不是“命令长得像不像 Docker”。

而是这三个问题：

每容器轻量 VM 的隔离模型，对你的本地开发是否真的更清楚？

OCI 镜像流转，能不能和现有 registry、CI、服务器跑通？

macOS 26 和 Apple silicon 的限制，对团队是不是可接受？

今天为什么选它

它排名不在最前，但今日新增仍然超过 1300 stars。

更重要的是，它把读者拉回一个更朴素的问题：

本地开发环境到底应该怎样隔离、怎样构建、怎样把镜像交到真实服务器。

这类基础设施话题不一定最会传播。

但它决定了很多项目能不能稳定开发、稳定测试、稳定交付。

如果你是 Mac 开发者，尤其是 Apple silicon 用户，apple/container 值得先放进观察清单。

现在未必马上迁移。

但它代表 Apple 正在把容器运行、虚拟化、网络、Keychain、launchd 这些 macOS 能力更深地接进开发者工具链。

这件事，比“又一个容器命令”更值得看。

欢迎关注公众号，后续每天一起看一个高质量开源项目：不堆名词，只看它解决什么问题、怎么上手、能不能用到真实工作流里。