架构差异是性能分化的根源
Docker 采用客户端-守护进程架构，dockerd 以 root 权限常驻后台，所有容器操作经过 daemon 中转。Podman 采用 fork-exec 架构，无需守护进程，每个容器作为独立子进程直接由用户启动。
这一根本差异决定了后续所有性能指标的走向：守护进程带来缓存优化和批量调度能力，但也带来固定的资源开销和额外的 IPC 往返延迟。
容器冷启动延迟：Podman 领先 15–38%
容器冷启动是最直观的性能差异场景。多份 2026 年基准测试在 AMD EPYC、Ryzen 9 7950X、AWS Graviton4 及裸金属 Ubuntu 24.04 环境下的测试结果高度一致：
| 测试场景 | Docker 27.x/29.x | Podman 5.4/5.8 | 差异 |
|---|---|---|---|
| Alpine 冷启动（rootful） | 1.23–1.42 s | 0.81–1.15 s | Podman 快 19–34% |
| Alpine 冷启动（rootless） | 2.40 s | 1.65 s | Podman 快 31% |
| Node.js 冷启动 | 1.61 s | 1.07 s | Podman 快 34% |
| Postgres 冷启动 | 2.42 s | 1.94 s | Podman 快 20% |
| 并发 10 容器启动 | 10.7 s | 5.2 s | Podman 快 51% |
Podman 的 crun（C 语言实现）OCI 运行时的容器创建延迟低于 Docker 的 runc（Go 实现）。在 p95 延迟指标上，Podman 的领先优势进一步拉大至 40%，证明其延迟分布更稳定、尾部延迟更低。
根因：Docker 每次
docker run需要经过dockerd → containerd → runc三层 IPC，额外增加 600–800ms 握手开销。Podman 直接 fork-exec 调用 crun，消除中间层。
内存资源开销：Podman 空闲接近零
| 指标 | Docker | Podman | 差异 |
|---|---|---|---|
| 守护进程空闲内存 | 80–180 MB | 0 MB | Podman 完全消除 |
| 每容器额外开销（nginx） | ~12–18 MB | ~8–10 MB | Podman 低 22–44% |
| 5 容器总 RSS | 68.2 MB | 12.4 MB | Podman 低 82% |
| 30 容器稳态内存 | 3.0 GB + 140 MB daemon | 2.55 GB | Podman 低 ~17% |
在资源受限的边缘设备、CI Worker 节点或高密度部署场景下，Podman 的零守护进程开销意味着更多内存可用于应用负载。
注意：Docker 的
dockerd + containerd双守护进程架构即使在无容器运行时也持续消耗 CPU 和内存，Podman 的conmon监控进程仅在容器运行时存在。
镜像构建速度：Docker BuildKit 仍占优
镜像构建是 Docker 保持优势的少数领域：
| 构建场景 | Docker (BuildKit) | Podman (Buildah) | 差异 |
|---|---|---|---|
| 简单 Node.js 应用（12 层） | 18.3 s | 19.1 s | Docker 快 4.4% |
| 多阶段 Go 应用（8 层） | 42.7 s | 43.9 s | Docker 快 2.8% |
| 大型 Python ML 镜像（24 层） | 127.4 s | 131.2 s | Docker 快 3.0% |
| 缓存增量构建（单层变更） | 2.1 s | 2.4 s | Docker 快 14.3% |
| Node monorepo 全量构建 | 3 分 17 秒 | 3 分 41 秒 | Docker 快 11% |
BuildKit 在并行层执行、缓存导入/导出和多平台构建方面的成熟度仍领先 Buildah。对于 CI/CD 管道中构建时间敏感的团队，Docker 或独立 BuildKit 仍是首选。
网络吞吐量：稳态基本持平，rootful 场景 Docker 领先
| 测试场景 | Docker | Podman | 差异 |
|---|---|---|---|
| HTTP 吞吐量（nginx, 1000 并发） | 78,100 RPS | 78,400 RPS | 基本持平 |
| iperf3 容器到主机（rootful bridge） | 42.1 Gbps | 38.7 Gbps | Docker 快 8.1% |
| iperf3（rootless slirp4netns） | 9.4 Gbps | 2.6 Gbps | Docker 快 3.6 倍 |
| iperf3（rootless pasta，Podman 5.0+） | 9.4 Gbps | ~9.2 Gbps | 差距缩至 2–3% |
一旦容器运行进入稳态，HTTP 应用层吞吐量两者几乎一致。 网络差异主要体现在 rootless 模式下的 bridge 网络实现方式。Podman 5.0 引入 pasta 网络后端后，rootless 场景的网络差距已从数倍缩小到可忽略水平。
磁盘 I/O 与存储
基于 fio 基准测试，Docker 和 Podman 在 overlayfs 叠加文件系统上的 I/O 性能基本一致：
| 指标 | Docker | Podman | 差异 |
|---|---|---|---|
| 顺序 I/O 吞吐量 | 1.82 GB/s | 1.79 GB/s | 基本持平 |
| 随机 4K I/O（IOPS） | 124,300 | 121,800 | 基本持平 |
两者底层使用相同的 overlayfs 驱动和内核 VFS 层，I/O 性能无实质差异。
并发扩展与容器密度
在大规模容器部署场景下，Podman 的无守护进程架构展现出更好的扩展性：
| 指标 | Docker | Podman |
|---|---|---|
| 50 容器顺序启动 | 24.1 s | 15.8 s |
| 50 容器并行启动 | 4.1 s | 3.6 s |
| 单机最大容器数 | ~1,180 | ~1,340 |
| 100+ 容器性能特征 | 轻微退化（daemon 瓶颈） | 线性扩展 |
Docker 的守护进程在管理数百个容器时可能出现性能退化，曾报告过 dockerd 进程内存泄漏至 8GB 的 incident。Podman 每个容器独立管理，无中央瓶颈，但每个 CLI 调用需重新初始化进程状态，高频小操作场景下 CPU 开销略高。
生命周期 CPU 开销
在 CI/CD 管道这类高频创建/销毁容器的场景下，容器生命周期管理的 CPU 开销成为重要指标：
| 运行时 | 1000 次生命周期总 CPU 时间 | 每次平均 |
|---|---|---|
| Docker | 142 s | 142 ms |
| Podman | 118 s | 118 ms |
| containerd | 78 s | 78 ms |
| CRI-O + crun | 64 s | 64 ms |
Podman 在生命周期 CPU 效率上优于 Docker，但不如 containerd/CRI-O 等专用容器运行时。对于 Kubernetes 生产节点，建议使用 containerd 或 CRI-O。
macOS/Windows 环境的特殊考量
在非 Linux 主机上，两者均在 Linux VM 内运行容器：
- Docker Desktop：VM 优化更成熟，VirtioFS 文件共享性能领先，macOS 上挂载源码目录的性能比 Podman Machine 快 15–25%
- Podman Machine 5.x：相比 v4 有显著改进，但文件同步和 VM 启动速度仍有差距
如果你的开发团队主要在 macOS 上工作，Docker Desktop 的开发体验和文件 I/O 性能目前仍更优。
总结：按场景选择
| 场景 | 推荐 | 原因 |
|---|---|---|
| 冷启动敏感（Serverless/CI） | Podman | 启动快 20–38%，空闲零内存 |
| 镜像构建频繁 | Docker | BuildKit 比 Buildah 快 5–15% |
| 边缘设备/资源受限 | Podman | 无 daemon 开销，内存效率高 40%+ |
| macOS 桌面开发 | Docker | Docker Desktop VM 和文件同步更成熟 |
| Kubernetes 生产节点 | containerd/CRI-O | 容器密度和 CPU 效率最优 |
| 大规模容器部署（100+） | Podman | 线性扩展，无 daemon 瓶颈 |
| 网络密集型 rootful 场景 | Docker | bridge 网络吞吐量更高 |
对于大多数开发者和运维团队，关键信息是：运行时性能差异对长运行服务几乎无影响，选择应基于架构偏好、安全需求、许可证成本和生态系统粘性，而非纯性能指标。