Apple Container 深度实战：当苹果自己下场做容器——从 Swift 原生轻量 VM 到 Mac 开发者第一个官方容器运行时的完全指南（2026）

54K+ Stars、GitHub 一天涨 1600+ Stars、Swift 编写、Apple Silicon 原生优化、OCI 兼容——Apple 用 container 项目给出了 Mac 上跑容器的第一个官方答案。

一、背景：Mac 上的容器困局

如果你是 Mac 开发者，过去十年大概率经历过这样的痛苦循环：

第一阶段：Docker Desktop 的甜蜜期（2016-2020）

Docker Desktop 是 Mac 上跑容器的标准答案。安装简单，命令行熟悉（毕竟是 Docker），生态丰富。一切看起来很美好。但代价是：一个 4GB+ 的虚拟机常驻后台，CPU 吃个不停，风扇嗡嗡响，内存想释放？没门——Linux VM 一直占着。

第二阶段：订阅政策之痛（2021-2023）

Docker 改了订阅政策，大团队要付费了。开发者社区炸了锅。民间替代品开始涌现：Lima、Colima、Podman……各种方案各有利弊，但没有一个有"官方"的底气。

第三阶段：OrbStack 的惊艳但隐忧（2023-2025）

OrbStack 以极致的轻量和速度惊艳了所有人，但作为一个商业产品，它的未来取决于公司的决策。开发者又一次站在了"依赖第三方"的老路上。

第四阶段：Apple 终于出手（2025-2026）

2025 年 6 月，Apple 在 GitHub 上默默发布了 apple/container——一个用 Swift 编写、专为 Apple Silicon 优化的容器运行时工具。一年后，2026 年 6 月 9 日，项目迎来 v1.0.0 的重大更新，日增 1611 Stars，登顶 Hacker News 超过 1000 分。

这不是又一个 Docker 替代品。这是 Apple 第一次正式参与容器生态游戏。

二、核心概念：apple/container 到底是什么？

2.1 一句话定义

apple/container 是一个命令行工具，让你在 Mac 上创建和运行 Linux 容器——但不是用传统的 namespace/cgroup 隔离，而是每个容器跑在一个独立的轻量级虚拟机（Lightweight VM）里。

2.2 关键特性速览

2.3 为什么是 macOS 26 ？

这不是 Apple 的平台绑架（好吧，有一点点），而是因为 macOS 26 引入了全新的虚拟化调度优化和 vmnet 网络增强：

• 新的 vmnet 框架支持容器间通信（macOS 15 只能隔离）
• 虚拟化框架的内存管理更高效，支持大量小 VM 并发
• 网络帮助进程和 vmnet 之间的子网分配问题得到修复

Apple 明确表示：不支持 macOS 15，不会修复在旧系统上的问题。

三、架构深度解析

3.1 整体架构

apple/container 的架构设计非常优雅，清晰地分层解耦：

┌─────────────────────────────────────────┐
│           container CLI（用户接口）         │
│         Swift 命令行工具                   │
├─────────────────────────────────────────┤
│     container-apiserver（Launch Agent）   │
│        接收 CLI 请求，管理容器生命周期      │
├──────────┬──────────────────────────────┤
│ container-│ container-network-vmnet      │
│ core-images│（虚拟网络 XPC Helper）        │
│（镜像管理  │                              │
│ XPC Helper│                              │
├──────────┴──────────────────────────────┤
│     containerization（Swift Package）     │
│     底层容器、镜像、进程管理               │
├─────────────────────────────────────────┤
│     Virtualization.framework              │
│     macOS 系统级虚拟化 API               │
├─────────────────────────────────────────┤
│     vmnet framework                       │
│     虚拟网络管理                          │
├─────────────────────────────────────────┤
│     Apple Silicon Hardware                 │
│     硬件虚拟化指令集                      │
└─────────────────────────────────────────┘

3.2 运行时架构详解

当你运行 container run 时，系统实际做了什么？

Step 1：CLI 请求 → apiserver

container CLI 通过 client library 向 container-apiserver 发送请求。apiserver 是一个 Launch Agent，在你执行 container system start 时启动，container system stop 时终止。

Step 2：apiserver 启动 XPC Helpers

• container-core-images：管理本地镜像存储，提供镜像管理 API
• container-network-vmnet：管理虚拟网络，为容器分配 IP 地址

Step 3：为容器创建独立 VM

对于每个容器，apiserver 启动一个 container-runtime-linux XPC Helper——这是该容器的专属运行时管理进程。

Step 4：VM 启动 → OCI 运行时接管

轻量 VM 启动后，里面的 OCI 运行时接管，挂载镜像的 rootfs，执行容器的 entrypoint 进程。

3.3 关键设计决策分析

决策一：CLI 和底层库分离

containerization 是一个独立的 Swift Package，不依赖 container CLI。这意味着什么？

// 理论上，你可以这样用
import Containerization

// 创建一个容器
let container = try Container(
    image: "nginx:latest",
    memory: .gigabytes(1),
    cpus: 2
)

try container.start()

这种设计让第三方工具可以直接调用底层库管理容器，不一定要走 CLI。这就是"平台"思维和"工具"思维的区别。

决策二：无常驻 Daemon

传统 Docker 有一个 dockerd 进程一直跑在后台。apple/container 的 apiserver 只在你需要时启动：

# 需要用的时候启动
container system start

# 不用了就关掉，释放所有资源
container system stop

这更符合 Mac 的使用习惯——用 Launchd 管理服务，需要时拉起，不需要时释放。

决策三：OCI 兼容是第一公民

Apple 没有搞自己的镜像格式，而是完全采用 OCI 标准。Docker Hub、GitHub Container Registry、自建 Harbor——所有标准 OCI registry 里的镜像都能直接用。

# Docker Hub 上的镜像直接拉
container image pull alpine:latest
container image pull nginx:latest
container image pull postgres:16

# GHCR 上的也没问题
container image pull ghcr.io/some/project:v1.0

# 构建出来的镜像也能推到任何 OCI 兼容的 registry
container image push my-registry.com/my-app:latest

这个选择至关重要——它意味着 apple/container 不是一座孤岛，而是容器生态的自然延伸。

四、与 Docker Desktop 的深度对比

4.1 架构本质区别

这是最重要的一张对比表，决定了所有性能差异的根源：

4.2 性能实测分析

启动速度

Docker Desktop 启动容器需要：

1. 确认 Linux VM 已运行（如未运行需等待 VM 启动）
2. dockerd 接收请求
3. containerd 创建容器
4. runc 启动进程

apple/container 启动容器需要：

1. 确认 apiserver 已运行
2. 创建轻量 VM（Apple Silicon 上接近亚秒级）
3. VM 内 OCI 运行时启动进程

结论：对于冷启动（apiserver 未运行），两者差距不大。但一旦系统服务就绪，apple/container 的容器启动更快，因为没有 daemon 的中间层。

内存占用

这是 apple/container 的杀手级优势：

# Docker Desktop — Linux VM 常驻
# Activity Monitor 显示：~2-4GB 固定占用

# apple/container — 按需分配
# 跑一个 nginx：仅占 ~200MB
# 停掉容器后：释放回宿主

Apple Silicon 的 Virtualization.framework 实现了内存按需分配：容器需要多少就分配多少，不是预先占用。macOS 26 的虚拟化调度进一步优化了这一点。

⚠️ 但有一个已知限制：容器内进程释放给 Linux 内核的内存页，目前不会自动归还宿主。如果你跑了大量内存密集型容器，可能需要偶尔重启来回收内存。

安全隔离

这是架构差异最根本的体现：

Docker Desktop 模型：

macOS Host
  └── Linux VM（共享内核）
       ├── Container A
       ├── Container B
       └── Container C

如果 Container A 触发了一个内核漏洞，Container B 和 C 也可能受影响。

apple/container 模型：

macOS Host
  ├── VM A（Container A，独立内核）
  ├── VM B（Container B，独立内核）
  └── VM C（Container C，独立内核）

每个容器有完全独立的内核。VM 级别的隔离意味着：即使一个容器的内核被攻破，攻击者也只是在那个微型 VM 里，离宿主机还有硬件虚拟化层的保护。

对于运行不可信代码（比如 CI/CD 中的第三方 PR 构建）的场景，这个安全模型的优势是压倒性的。

五、安装与配置完全指南

5.1 系统要求（必读）

硬性要求：

• ✅ Apple Silicon Mac（M1/M2/M3/M4/M5 系列）
• ✅ macOS 26 或更高版本
• ❌ Intel Mac：不支持
• ❌ macOS 15 或更低：不支持，且不会修复

为什么只支持 macOS 26？

因为 macOS 26 引入了虚拟化和网络栈的关键改进。官方原文：

"container is supported on macOS 26, since it takes advantage of new features and enhancements to virtualization and networking in this release. We do not support older versions of macOS and the container maintainers typically will not address issues that cannot be reproduced on macOS 26."

翻译：别用旧系统，出了 bug 我不修。 很 Apple 的态度。

5.2 安装步骤

# Step 1：去 GitHub Releases 下载签名安装包
# https://github.com/apple/container/releases

# Step 2：双击 .pkg 文件安装
# 输入管理员密码，文件会安装到 /usr/local

# Step 3：启动系统服务
container system start

# Step 4：验证安装
container --version

就这么简单。没有 brew install、没有 cargo install、没有下载二进制文件手动放 PATH——Apple 做的是标准的 macOS .pkg 安装包，签过名的。

5.3 升级与卸载

# ===== 升级 =====

# 先停止服务
container system stop

# 使用内置升级脚本
/usr/local/bin/update-container.sh

# ===== 降级到指定版本 =====
/usr/local/bin/uninstall-container.sh -k  # -k 保留用户数据
/usr/local/bin/update-container.sh -v 0.3.0

# ===== 卸载 =====

# 保留数据卸载（重装时数据还在）
/usr/local/bin/uninstall-container.sh -k

# 连数据一起删
/usr/local/bin/uninstall-container.sh -d

六、命令行实战：从入门到生产

6.1 完整命令参考

apple/container 的 CLI 设计非常贴近 Docker 的使用习惯，降低迁移成本。以下是完整命令分类：

系统管理

# 启动/停止系统服务
container system start
container system stop

# 查看系统信息
container system info

镜像管理

# 拉取镜像
container image pull alpine:latest
container image pull nginx:latest
container image pull postgres:16

# 列出本地镜像
container image list

# 删除镜像
container image delete nginx:latest

# 推送镜像到 registry
container image push my-registry.com/my-app:latest

# 从 tar 包导入镜像
container image import ./my-image.tar

# 导出镜像为 tar 包
container image export my-app:latest -o ./my-image.tar

# 构建镜像
container build -t my-app:latest .

容器管理

# 运行容器
container run -it alpine:latest sh              # 交互式
container run -d --name web -p 8080:80 nginx    # 后台运行

# 创建但不启动
container create --name my-db postgres:16

# 启动已创建的容器
container start my-db
container start --attach --interactive my-db     # 带输出和交互

# 停止容器
container stop my-db
container stop --all                             # 停止所有
container stop --signal SIGTERM --time 10 my-db  # 自定义信号和超时

# 强制杀死
container kill my-db
container kill --all

# 删除容器
container delete my-db
container delete --all                           # 删除所有
container delete --force --all                   # 包括运行中的

# 列出容器
container list                    # 只看运行中的
container list --all               # 包括停止的
container list --format json       # JSON 格式输出

# 在运行中的容器内执行命令
container exec -it my-db psql -U postgres
container exec my-web curl localhost

网络管理（macOS 26 专属）

# 创建自定义网络
container network create my-network

# 列出网络
container network list

# 删除网络
container network delete my-network

# 运行容器时指定网络
container run --network my-network nginx:latest
container run --network my-network,mac=02:42:ac:11:00:02 nginx:latest

日志查看

# 查看容器日志
container logs my-web
container logs --follow my-web    # 实时跟踪

卷和挂载

# Bind mount（绑定挂载）
container run -v /host/path:/container/path nginx:latest

# 只读挂载
container run -v /host/config:/etc/nginx/conf.d:ro nginx:latest

# tmpfs 挂载
container run --tmpfs /tmp:rw,size=64M nginx:latest

# 自定义 mount 类型
container run --mount type=volume,source=mydata,target=/data nginx:latest

6.2 资源限制

apple/container 支持精细的资源控制：

# CPU 限制（核心数）
container run -c 2 nginx:latest          # 2 个 CPU 核心

# 内存限制
container run -m 1G nginx:latest          # 1GB 内存
container run -m 2048M nginx:latest       # 2048MB
container run --memory 16G postgres:16      # 16GB（PostgreSQL 需要）

# 组合使用
container run -c 4 -m 8G -e NODE_ENV=production node:18

内存分配的粒度是 1MiByte，且支持 K/M/G/T/P 后缀。

6.3 Dockerfile 构建

apple/container 使用 BuildKit 在隔离环境中构建镜像：

# 标准 Dockerfile 完全兼容
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:18-alpine AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

# 基础构建
container build -t my-app:latest .

# 指定 Dockerfile 路径
container build -f docker/Dockerfile.prod -t my-app:prod .

# 传递构建参数
container build --build-arg NODE_VERSION=18 -t my-app:latest .

# 多阶段构建（只构建 production 阶段）
container build --target production -t my-app:prod .

# 多标签
container build -t my-app:latest -t my-app:v1.0.0 -t my-app:stable .

# 无缓存构建
container build --no-cache -t my-app:latest .

# 设置构建资源的 CPU 和内存限制
container build -c 4 -m 4G -t my-app:latest .

6.4 环境变量配置

# 内联设置
container run -e NODE_ENV=production -e PORT=3000 node:18

# 从宿主继承
container run -e HOME -e LANG node:18

# 从文件读取
container run --env-file ./production.env node:18

.env 文件格式：

# 支持注释（# 开头）和空行
DATABASE_URL=postgres://user:pass@db:5432/mydb
REDIS_URL=redis://cache:6379
NODE_ENV=production
# DEBUG=verbose

6.5 高级功能

Rosetta 支持（x86_64 兼容）

# 在 ARM Mac 上运行 x86_64 镜像
container run --rosetta amd64/python:3.11 python --version

这对于需要运行 x86_64 软件的场景非常有用，比如某些只提供了 x86_64 二进制的工具。

自定义 Init 镜像

# 使用自定义 init 镜像
container run --init-image local/custom-init:latest nginx:latest

自定义 init 镜像可以在 OCI 容器启动前执行 VM 级别的操作：

• 运行 VM 级别的守护进程
• 配置 eBPF 过滤器
• 调试 init 进程

自定义内核

# 使用自定义 Linux 内核
container run -k /path/to/custom/bzImage alpine:latest

这是一个强大的高级特性，让你可以为特定场景编译优化的内核。

SSH 转发

# 转发宿主机的 SSH agent socket 到容器
container run --ssh alpine:latest

在容器里可以直接用宿主机的 SSH 密钥进行 Git 操作等。

Linux Capabilities 控制

# 添加特定 capability
container run --cap-add CAP_NET_RAW alpine:latest

# 移除特定 capability
container run --cap-drop CAP_NET_RAW alpine:latest

# 添加所有 capabilities
container run --cap-add ALL alpine:latest

只读文件系统

# 容器 rootfs 只读
container run --read-only -v /tmp:/tmp alpine:latest

安全最佳实践：如果应用不需要写 rootfs，就用 --read-only。

七、生产级实战场景

7.1 本地开发环境

最直接的使用场景——替代 Docker Desktop 跑本地开发用的数据库、缓存、消息队列等。

# 启动 PostgreSQL
container run -d \
  --name dev-postgres \
  -e POSTGRES_USER=dev \
  -e POSTGRES_PASSWORD=dev123 \
  -e POSTGRES_DB=myapp \
  -p 5432:5432 \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16

# 启动 Redis
container run -d \
  --name dev-redis \
  -p 6379:6379 \
  redis:7-alpine

# 启动 MongoDB
container run -d \
  --name dev-mongo \
  -e MONGO_INITDB_ROOT_USERNAME=admin \
  -e MONGO_INITDB_ROOT_PASSWORD=admin123 \
  -p 27017:27017 \
  mongo:7

# 查看状态
container list

# 不用时一键清理
container stop --all
container delete --all

对比 Docker Desktop 的优势：停掉所有容器后，内存立刻释放。不需要退出 Docker Desktop 应用，不需要杀掉 Linux VM。

7.2 Web 应用开发

# Dockerfile.dev
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 5173
CMD ["npm", "run", "dev"]

# 构建并运行
container build -t my-webapp:dev .
container run -d \
  --name webapp-dev \
  -p 5173:5173 \
  -v $(pwd)/src:/app/src \
  -e NODE_ENV=development \
  my-webapp:dev

# 查看日志
container logs --follow webapp-dev

# 进容器调试
container exec -it webapp-dev sh

7.3 CI/CD 本地模拟

由于 apple/container 提供了 VM 级别的隔离，它特别适合在本地模拟 CI/CD 环境运行不可信代码：

# 构建一个包含不可信代码变更的镜像
container build -t pr-test:latest .

# 在受限环境中运行测试
container run --rm \
  --read-only \
  --cap-drop ALL \
  --memory 2G \
  --cpus 2 \
  -e CI=true \
  pr-test:latest \
  npm run test:ci

VM 隔离确保了即使测试代码中有恶意内容，也不会影响宿主机。

7.4 多容器项目脚本

由于目前没有 docker-compose 的直接替代品，多容器项目需要用脚本管理：

#!/bin/bash
# start.sh — 多容器项目启动脚本

# 创建网络
container network create app-network 2>/dev/null || true

# 启动数据库
container run -d \
  --name app-db \
  --network app-network \
  -e POSTGRES_USER=app \
  -e POSTGRES_PASSWORD=secret \
  -e POSTGRES_DB=app \
  -v app-pgdata:/var/lib/postgresql/data \
  postgres:16

# 等待数据库就绪
echo "Waiting for database to be ready..."
sleep 5

# 启动 Redis
container run -d \
  --name app-redis \
  --network app-network \
  redis:7-alpine

# 启动应用
container run -d \
  --name app-api \
  --network app-network \
  -e DATABASE_URL=postgres://app:secret@app-db:5432/app \
  -e REDIS_URL=redis://app-redis:6379 \
  -p 8080:8080 \
  my-app:latest

echo "All services started!"
container list

#!/bin/bash
# stop.sh — 清理脚本

container stop app-api app-redis app-db
container delete app-api app-redis app-db
container network delete app-network

这种脚本化的方式虽然不如 docker-compose 优雅，但胜在透明、可定制、没有隐藏的魔法。

八、性能优化指南

8.1 内存优化

理解内存模型

apple/container 使用 macOS 的内存 ballooning 技术，但实现是有限的：

# 设置内存限制
container run -m 512M alpine:latest    # 实际使用可能远小于 512M

# macOS Activity Monitor 中可能看到：
# - 容器声明了 512M
# - 实际只用了 50M
# - 但 Linux 内核释放的内存不会自动归还宿主

内存优化策略

# 1. 合理设置内存限制，不要过度分配
container run -m 256M nginx:latest       # nginx 不需要 1G
container run -m 512M node:18             # Node 应用按需

# 2. 对内存密集型容器，定期重启回收内存
# 可以配合 cron 或 launchd 定时任务

# 3. 停止不用的容器
container stop --all

# 4. 停止整个系统服务释放全部资源
container system stop

8.2 CPU 优化

# 为 I/O 密集型服务分配较少 CPU
container run -c 1 redis:7-alpine

# 为计算密集型服务分配更多 CPU
container run -c 4 --memory 8G python:3.11 train.py

# 不设置 CPU 限制（使用默认调度）
container run -m 2G postgres:16

8.3 网络优化

# 设置自定义 MAC 地址（某些网络环境需要）
container run \
  --network default,mac=02:42:ac:11:00:05 \
  nginx:latest

# 自定义 MTU
container run --network default,mtu=1400 nginx:latest

# 自定义 DNS
container run --dns 8.8.8.8 --dns-search example.com nginx:latest

8.4 构建优化

# 利用缓存加速构建
container build -t my-app:cache .

# 修改代码后增量构建（自动利用层缓存）
container build -t my-app:latest .

# 多平台构建
container build --platform linux/arm64 -t my-app:arm64 .

# 并行下载加速镜像拉取
container image pull --max-concurrent-downloads 10 nginx:latest

九、macOS 15 上的已知限制

如果你（或你的团队成员）还在 macOS 15 上，需要注意以下限制：

网络故障排查（macOS 15）

# 检查 vmnet 分配的 CIDR
# 正常情况：192.168.64.1/24
# 如果不匹配，参考官方 troubleshooting 文档

# 临时解决方案：重启容器服务
container system stop
container system start

强烈建议：如果你在使用 Apple Container，直接升级到 macOS 26。体验差距是巨大的。

十、与替代方案对比

10.1 四大替代方案一览

10.2 什么时候选 apple/container？

应该选 apple/container 的情况：

• 你是个人 Mac 开发者，已升级 macOS 26
• 你需要跑本地数据库、缓存等开发依赖
• 安全隔离对你很重要（运行不可信代码）
• 你厌倦了 Docker Desktop 的资源占用
• 你想为 Apple Silicon 原生优化投入

应该继续用 Docker Desktop / OrbStack 的情况：

• 你的团队有 Linux 和 Windows 用户
• 你重度依赖 docker-compose 或 kubernetes 工作流
• 你需要 Windows 容器支持
• 你的 CI/CD 流水线预设了 Docker 环境

10.3 最佳实践：混合使用

实际上，很多开发者会采用混合策略：

# 日常开发：apple/container（轻量、快速）
container run -d --name dev-postgres -p 5432:5432 postgres:16

# 复杂编排项目：OrbStack/Docker（compose 支持）
# docker compose up -d

# CI/CD：保持 Docker（标准环境）

没有银弹，选择对的工具做对的事。

十一、技术前瞻与行业影响

11.1 重新定义「容器」

apple/container 最深远的贡献不在于工具本身，而在于它提出的问题：容器必须是 namespace 隔离吗？

传统定义中，容器 = Linux namespace + cgroup + OCI 镜像。但 apple/container 证明了：当硬件虚拟化足够高效时，每个容器一个 VM 也能达到相近的性能，同时获得更强的安全隔离。

这可能改变容器技术的演进方向：

1. 轻量 VM 成为新的隔离标准：不只是 Apple，其他平台也可能跟进
2. 安全容器成为默认：VM 级别隔离从「可选」变成「标配」
3. 平台原生容器运行时崛起：不再是 Docker 一家独大

11.2 对开源容器生态的影响

Apple 作为顶级科技公司参与容器标准制定，意味着：

• OCI 标准的重要性进一步提升：Apple 选择了 OCI 兼容而非自搞一套
• containerization 库可能成为 Swift 生态的容器基础设施：不只是 CLI 工具
• 更多厂商可能推出平台原生方案：Google（Android）、Microsoft（Windows）会跟进吗？

11.3 对开发者的影响

短期影响（现在）：

• Mac 开发者多了一个可靠的选择
• Docker Desktop 的垄断地位被削弱
• 个人开发者可以摆脱订阅费用

长期影响（未来 1-2 年）：

• apple/container 的生态会逐渐成熟（compose 支持？k8s 集成？）
• 多容器编排工具会涌现
• 其他平台可能推出类似的 VM-per-container 方案

十二、踩坑与排障手册

12.1 常见问题

Q：安装后 container system start 报错？

# 确认系统版本
sw_vers
# ProductName:		macOS
# ProductVersion:		26.x.x

# 确认是 Apple Silicon
uname -m
# arm64

# 如果是 Intel Mac 或 macOS 15，这个工具不适合你

Q：容器内网络不通？

# macOS 26 上检查网络
container network list

# macOS 15 上：这是已知限制，升级到 macOS 26

# 检查 DNS
container run --dns 8.8.8.8 alpine:latest ping -c 3 google.com

Q：镜像拉取失败？

# 检查 registry 连通性
container image pull docker.io/library/alpine:latest

# 内部 registry 使用 HTTP
container run --scheme http my-registry.local:5000/my-app:latest

# 自动模式（默认）：内网用 HTTP，外网用 HTTPS
container run --scheme auto my-app:latest

Q：内存不释放？

# 这是已知限制：容器内释放的内存页不会自动归还宿主

# 解决方案 1：停止并重新创建容器
container stop my-container
container delete my-container
container run -d --name my-container ... my-image:latest

# 解决方案 2：停止系统服务（彻底释放）
container system stop
container system start

12.2 调试技巧

# 使用 --debug 标志获取详细日志
container run --debug nginx:latest
container start --debug my-container
container stop --debug my-container
container delete --debug my-container
container exec --debug my-container ls /

# 查看容器日志
container logs my-container
container logs --follow my-container

# 导出为 JSON 方便脚本处理
container list --format json
container list --format yaml
container list --format toml

12.3 从 Docker 迁移的注意事项

1. docker-compose 没有直接替代：需要写成 shell 脚本
2. Dockerfile 完全兼容：不需要改
3. volume 数据不共享：需要重新 pull/build 镜像
4. 网络配置有差异：macOS 26 上才能用自定义网络
5. 部分 flag 名不同：比如 --rm 对应 --remove，但 --rm 也支持

十三、总结

apple/container 的定位

apple/container 不是一个「更好的 Docker Desktop」。它是一个有独立设计哲学的容器运行时，基于「每容器一个轻量 VM」的架构选择，在安全性和资源效率上做出了差异化。

值得关注的理由

1. 官方背书：Apple 维护，不会突然停更
2. VM 级隔离：安全敏感场景的最佳选择
3. Swift 生态：containerization 库为 Swift 开发者提供了容器管理能力
4. 资源效率：按需分配，停掉就释放
5. OCI 兼容：不锁定，和现有容器生态无缝衔接

需要观望的理由

1. 平台限制：仅 macOS 26+ Apple Silicon
2. 生态早期：compose、k8s 等工具链待完善
3. 功能缺失：仍在快速迭代中，API 可能有 breaking changes

最终建议

如果你是 macOS 26 的 Apple Silicon 用户，现在就值得试用。把它作为日常开发的轻量替代品，跑跑数据库、测测代码。但暂时不要在需要跨平台一致性的生产环境里全面切换。

Apple 做了一件十年来应该做的事——给 Mac 开发者一个官方的容器方案。不管它最终能不能取代 Docker Desktop，它的存在本身就是对容器生态的一记重要推动。

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

底层库：https://github.com/apple/containerization

本文基于 apple/container v1.0.0 版本编写，项目仍在快速迭代中，请以官方文档为准。