Mac 跑 Linux 容器，苹果这次终于做成了
Apple 官方开源 · 48,166 Star · 最新版本 1.1.0
苹果在 Mac 上跑 Linux 容器，给出了自己的答案：container。
这个项目用 Swift 编写，面向 Apple silicon，并不是给 Docker 套一层新界面。它的核心变化是：每个容器都运行在独立的轻量虚拟机里，同时继续使用 OCI（开放容器倡议）兼容镜像。
01
每个容器一台轻量虚拟机
Mac 上常见的容器方案通常先启动一台 Linux 虚拟机，再把多个容器放进去。container 采用另一条路线：每个容器对应一台轻量虚拟机。
最直观的变化是隔离边界更清楚。不同容器不共享同一台 Linux 虚拟机；向容器开放宿主机目录时，也只挂载这个容器真正要用的数据。
不过这条路线也有代价。项目文档明确提到，macOS 的内存回收能力还不完整。运行大量高内存容器后，已经在 Linux 内释放的部分内存页，不一定及时归还 macOS，必要时要重启容器降低占用。
02
镜像生态没有另起炉灶
container 读取和生成标准 OCI 镜像，可以从常规镜像仓库拉取，也能把构建结果推送回去。它创建的镜像不限定只能由苹果这套工具运行。
命令行覆盖了开发中常用的操作：创建、启动、停止和删除容器，执行容器内命令，查看日志与资源使用，构建镜像，管理镜像仓库、网络和卷。
仓库凭据可以从环境变量读取，也可以保存在 macOS Keychain（钥匙串）中。使用环境变量时要注意进程环境的可见范围，避免把令牌写进脚本或提交到仓库。
03
它和 macOS 结合得更深
项目底层使用 Apple 的 Containerization 框架，并接入多项系统能力：Virtualization（虚拟化）框架负责 Linux 虚拟机，vmnet 负责虚拟网络，XPC 负责进程通信，launchd 管理后台服务，运行记录则写入统一日志系统。
执行 container system start 后，系统会启动 API 服务、镜像管理和网络等辅助进程；创建容器时，再为对应容器启动独立的 Linux 运行时进程。
04
硬件和系统门槛很明确
正式使用要求 Apple silicon Mac，官方支持 macOS 26。源码构建还需要 Xcode 26。
虽然部分代码和文档提到 macOS 15，但网络隔离、多网络和容器地址分配都有已知限制，维护者也说明不会处理只能在旧系统复现的问题。Intel Mac 不在支持范围内。
所以它暂时不是所有 Mac 团队都能统一采用的方案。机器型号和系统版本不一致时，其他容器工具还得保留。
05
安装会进入系统目录并启动服务
官方建议从 GitHub Release 下载签名安装包，安装时需要管理员权限，文件写入 /usr/local。首次启动还会下载推荐的 Linux 内核和基础文件系统。
更新脚本会访问 GitHub API、下载发布包，再调用系统安装器。脚本优先选择签名包；如果没有找到，会询问是否改用未签名包。更稳妥的做法是只安装签名版本，并在更新前停止现有服务。
卸载脚本提供两个选择：-k 保留用户数据，-d 删除用户数据。后者会清理 ~/Library/Application Support/com.apple.container，执行前要确认本地镜像、容器和配置是否还需要。
06
源码审查发现了什么
我检查了项目的安装、更新、卸载、网络请求、插件加载、凭据处理、文件写入和后台服务代码，没有发现自定义遥测、隐藏上传或可疑外联逻辑。
但“没发现后门”不等于“没有风险”。它本身就是高权限基础设施：会启动后台服务、创建虚拟网络、下载内核与镜像、挂载宿主机目录，也允许执行容器内命令。实际使用中更该防范的是不可信镜像、范围过大的目录挂载、泄露的仓库令牌和来源不明的插件。
插件系统会扫描指定目录中的配置和二进制文件，并可将插件注册为 launchd 服务。因此，只应安装可信来源的插件，不能把普通容器隔离当成对恶意插件的保护。
07
适合哪些人
如果你使用 Apple silicon 和 macOS 26，希望容器工具更贴近系统原生能力，又要兼容 OCI 镜像，container 值得关注。
如果团队依赖跨平台一致体验、需要兼容 Intel Mac 或旧版 macOS，现阶段不宜直接替换现有方案。它更像苹果给出的新架构方向，而不是所有场景下的 Docker 平替。
截至 2026 年 7 月 22 日，项目约有 48.2k Star，最新稳定版本为 1.1.0，仍保持活跃更新。
项目地址：https://github.com/apple/container
