在 Mac 上跑容器：方案选择与架构差异

容器在 Linux 上是内核功能，macOS 没有这个内核。所以 Mac 上的每一种容器方案，本质都是先跑一个 Linux 虚拟机，再在里面跑容器。几个方案的差别在于这台虚拟机由谁管理、占多少资源、以及授权条款。

理解这一点能解释很多现象：为什么容器会占内存、为什么文件读写比 Linux 上慢、为什么有些镜像跑不起来。

开始之前

需要会用终端执行命令。本文不重复容器本身的概念，重点在 macOS 上的选择与差异。

先确认你真的需要容器。只是要一个特定版本的 Node 或 Python，用 mise 更简单也更快。容器解决的是「完整的运行环境要一致」，例如需要特定版本的数据库、消息队列，或者要和同事、CI 保持完全相同的系统依赖。

三种方案的取舍

方案	是什么	授权模式
Docker Desktop	官方出品，含图形界面与 Kubernetes	个人、教育及小规模组织免费，超过规模门槛需订阅
OrbStack	第三方，主打启动快、占用低	个人非商业用途免费，商业用途需付费许可
Colima	开源命令行工具，无图形界面	开源免费

授权条款是这里最容易出事的一项，而且和技术无关。

Docker Desktop 对组织规模设了门槛，员工数与年收入两个条件都低于门槛才适用免费条款；超过任一条件即需订阅。Docker 订阅条款

OrbStack 的条款更严格，没有组织规模豁免：自由职业、公司、非营利机构和政府机构使用都需要购买许可，安装后有一段试用期。个人非商业使用免费。OrbStack 授权说明

Colima 是开源项目，没有这类限制。它在后台用 Lima 管理虚拟机，提供标准的 docker 命令行体验，但没有图形界面。

具体价格以官方页面为准，本文不记录金额。在公司设备上做决定之前，先问清楚 IT 或法务已经批准了哪一个——容器工具的授权合规问题通常在审计时才爆发，而工具本身不会因为未授权而停止工作。

Apple 芯片上的架构问题

Apple 芯片是 arm64 架构，而大量现成镜像只提供 amd64（x86_64）版本。拉取时可能看到类似提示：

The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8)

这不是错误，是警告：容器仍会通过模拟运行，但速度可能慢几倍，并且部分程序会直接崩溃。遇到「在同事的 Intel 机器上好好的，在我这里特别慢」，先查这一项。

明确指定平台：

docker run --platform linux/arm64 nginx

--platform 指定要拉取和运行的架构版本。镜像提供 arm64 版本时，这样能拿到原生版本。只有 amd64 版本时，改成 linux/amd64 让它明确走模拟，至少行为可预期。

查看一个镜像支持哪些架构：

docker manifest inspect nginx

manifest inspect 显示镜像清单，输出里的 architecture 字段列出可用架构。这条命令需要能访问镜像仓库。

资源占用是真实的

那台 Linux 虚拟机常驻内存。不用容器的时候，它仍然占着你分配给它的资源。

在活动监视器里能看到对应进程，判断方法见进程与活动监视器。三种方案都允许调整分配给虚拟机的 CPU 与内存上限——分配过多会挤占日常使用，分配过少会让构建失败。从较小的值开始，遇到构建因内存不足失败再往上调。

不用的时候真的关掉它。Docker Desktop 和 OrbStack 都可以从菜单栏退出，Colima 用 colima stop。把容器方案设成开机自启之前，先确认你每天都会用到——这一项也会出现在登录项与后台代理的检查清单里。

文件读写慢是设计使然

把主目录挂载进容器时，读写要跨越虚拟机边界。文件数量大的场景（例如在挂载目录里装依赖、跑测试）会明显慢于 Linux 原生。

这不是配置错误，各方案只是在不同程度上优化了这条路径。常见做法是把频繁读写的目录（依赖目录、构建缓存）放在容器内的卷里，而不是挂载出来。

检查结果

装好任一方案后：

docker run --rm hello-world

--rm 让容器退出后自动删除，避免积累无用容器。看到欢迎信息说明整条链路通了。

然后确认架构：

docker run --rm alpine uname -m

uname -m 输出机器架构。在 Apple 芯片上应当看到 aarch64；如果看到 x86_64，说明这个镜像走了模拟。

动手练习

用一个可丢弃的容器完成一轮对照：

1. 执行 docker run --rm alpine uname -m，记下架构。
2. 执行 docker run --rm --platform linux/amd64 alpine uname -m，比较输出和启动耗时。
3. 打开活动监视器，记录容器方案在空闲时占用的内存。
4. 退出容器方案，再看一次内存变化。

成功标准是能说出第 2 步为什么变慢，以及第 3、4 步的差值——这个数字决定了它值不值得常驻。练习用的都是临时容器，--rm 保证不留痕迹。

返回开发环境