docker镜像分层通过只读层叠加、内容哈希标识与联合文件系统实现高效分发：拉取时仅传输缺失层，本地复用相同sha256层，仓库端跨镜像去重存储，并支持cdn按层缓存及构建缓存共享。
docker 镜像分层是镜像仓库实现高效分发的底层技术基础，核心在于“只传差异、按需拉取、本地复用”。它不是靠压缩或带宽提升，而是通过结构设计天然减少传输量和存储开销。
分层机制让每次拉取只下载缺失部分
镜像由多个只读层组成，每层对应 Dockerfile 中一条指令（如 FROM、RUN、COPY），并以内容哈希（SHA256）唯一标识。当客户端执行 docker pull 时，仓库先比对本地已有的层哈希与远程镜像的层列表，仅返回客户端缺失的层数据。
- 例如：两个基于 ubuntu:22.04 的镜像，即使应用代码完全不同，基础操作系统层在本地只需存储一份，拉取第二个镜像时跳过该层
- 若某服务仅更新了配置文件（COPY config.yaml /app/），拉取新镜像时通常只传输这一层（几 KB 到几 MB），而非整个镜像（几百 MB）
仓库后端利用分层做存储去重与缓存优化
镜像仓库（如 Harbor、Registry）在存储层主动识别并合并相同哈希的层，无论来自哪个镜像、哪个项目，物理上只存一份：
- 对象存储（S3/Ceph）中，每个层作为独立对象，通过 SHA256 命名，天然支持跨镜像去重
- CDN 或边缘节点缓存时，按层粒度缓存，热门基础层（如 alpine:3.20、python:3.11-slim）被高频复用，显著降低源站压力
- 企业级仓库还支持“镜像复制”策略——仅同步变更层，跨地域同步耗时下降 60% 以上
构建与推送阶段就为分发效率铺路
高效分发的前提是镜像本身具备良好分层结构。这依赖构建侧的合理设计：
- 稳定层前置：把不变的基础镜像、运行时、依赖安装放在 Dockerfile 上方，确保这些层能被大量镜像共享和缓存
- 避免层污染：不用 RUN apt-get update && apt-get install 分两行（会生成空层），也不在 COPY 后立即 RUN rm —— 删除操作会新增层且无法回收空间
- 启用构建缓存共享：CI 系统中挂载构建缓存目录（如 BuildKit 的 --cache-from），使不同流水线间也能复用中间层
配合协议与客户端行为进一步提速
分层优势需配套协议支持才能落地：
- Docker Registry API 支持 GET /v2/
/blobs/ 按层拉取，客户端可并发请求多个层，不阻塞整体流程 - 现代客户端（Docker 24+、nerdctl）默认启用 zstd 压缩 和 分块校验，单层传输失败只需重试该块，不影响其他层
- Kubernetes 节点可通过 imagePullPolicy: IfNotPresent + 本地已有层，跳过网络拉取；结合 DaemonSet 预加载常用层，实现秒级启动
