oci不是docker功能升级，而是推动容器生态从“docker主导”转向“标准驱动”的关键转折点：它打破docker私有格式垄断，倒逼其架构解耦为cli/daemon/containerd/runc分层，并确立跨平台一致性的最小共识边界。
Docker 版本演进过程中，OCI 不是 Docker 的功能升级，而是推动整个容器生态从“Docker 主导”走向“标准驱动”的关键转折点。
打破 Docker 私有格式垄断
早期 Docker（1.0–1.9）使用自研的镜像格式和运行时（libcontainer），虽快速普及，但其镜像无法被其他工具原生识别。当 Kubernetes 等编排系统兴起后，这种封闭性成为扩展瓶颈。OCI 在 2015 年成立，直接促使 Docker 将 libcontainer 捐献为 runc，并承诺兼容 OCI 运行时规范——这相当于把核心运行能力“标准化”，让 containerd、CRI-O 等替代运行时得以合法接入。
倒逼 Docker 架构解耦与模块化
为满足 OCI 规范，Docker 自 17.06 版本起将引擎拆分为：Docker CLI（用户接口）、Docker Daemon（调度协调）、containerd（生命周期管理）、runc（实际执行）。这种分层不是简单重构，而是主动适配 OCI Runtime Spec 和 Image Spec 的结果。比如，Docker build 后生成的镜像，底层结构已严格遵循 OCI 镜像规范中的 manifest.json、layers/、config.json 三要素，而非旧版 tar 包直打方式。
使多运行时共存成为可能
- Kubernetes 通过 CRI 接口调用符合 OCI Runtime Spec 的实现（如 containerd + runc 或 CRI-O + crun），不再绑定 Docker；
- 构建工具如 Buildah、Podman、Kaniko 均按 OCI Image Spec 打包，产出的镜像可被任意 OCI 兼容运行时加载；
- 安全增强型运行时（如 Kata Containers、gVisor）也基于 OCI Runtime Spec 设计，只需替换 runc 即可接入现有流程。
确立跨平台一致性的技术底线
OCI 规范本身不规定功能多寡，而是划出“最小共识边界”。例如：所有 OCI 运行时必须支持 Linux namespaces/cgroups 配置、必须按 bundle 目录结构读取 config.json、镜像必须用 content-addressable 方式索引 layer。Docker 后续版本（如 20.10+）在引入 BuildKit、Rootless 模式等功能时，都确保不破坏这一边界——新能力是叠加在 OCI 基石之上，而非绕过它。
