docker hub以分层方式存储镜像，每层通过sha256内容寻址唯一标识，支持跨镜像共享；pull时先获取manifest，再并行下载未缓存层，结合cdn和校验机制实现高效分发与一致性保障。
Docker Hub 本身不直接存储完整的镜像文件，而是以分层（layer）方式存储和分发镜像——每个镜像由一组只读的、按顺序叠加的文件系统层组成，底层复用、上层增量，这是高效存储与快速拉取的核心机制。
镜像层如何被存储
Docker Hub 后端使用基于内容寻址（content-addressable）的对象存储系统（如 Amazon S3 或自研分布式存储），每层对应一个唯一的 SHA256 摘要（例如 sha256:abc123...）。该摘要由层内容（tar 包 + 元数据）经哈希计算得出，相同内容必然生成相同摘要，天然支持跨镜像共享层。
- 构建时每条
RUN、COPY、ADD等指令生成一层，Docker 客户端上传前会先计算其摘要，仅上传本地不存在的层 - 镜像 manifest（v2 schema 2）是一个 JSON 文件，记录所有层的摘要、MIME 类型、大小及配置层（config layer）位置
- 配置层（config layer）不包含文件系统，只描述镜像元信息：环境变量、入口命令、历史构建信息等
镜像层如何被分发
当用户执行 docker pull 时，客户端先获取 manifest，再并行下载所需层（跳过本地已缓存的层），最后按顺序组装成可运行的镜像。整个过程依赖 Docker Registry HTTP API（v2 协议）完成鉴权、发现与流式传输。
- Registry 返回 302 重定向，引导客户端直连 CDN 或对象存储边缘节点下载层 blob，减轻 Hub 主服务压力
- 层以 tar.gz 形式压缩传输，客户端接收后校验 SHA256 摘要，确保完整性与一致性
- 多架构镜像（如 amd64/arm64）通过 manifest list（即 index）统一索引，客户端根据
runtime.GOARCH自动选择匹配平台的子 manifest
为什么能节省带宽和磁盘空间
层复用是关键。比如 100 个基于 ubuntu:22.04 的镜像，基础操作系统层只在 Hub 存一份，在本地也只需下载一次；后续镜像只下载差异层（如应用代码、依赖包）。
- 同一基础镜像的不同 tag（如
python:3.9-slim和python:3.9-alpine）可能共享部分中间层，但因基础 rootfs 不同，复用有限 -
docker image prune -a删除未被任何镜像引用的层，释放空间；而docker system df可查看层的实际磁盘占用与复用情况
实际影响与注意事项
层设计带来便利，但也引入隐性约束：层不可变、顺序敏感、层数过多会拖慢构建与拉取速度（尤其网络不佳时），且历史层残留可能泄露敏感信息。
- 推荐使用多阶段构建（multi-stage build），将编译产物从构建阶段 COPY 到精简运行阶段，避免把编译工具链打包进最终镜像
- 避免在靠前层写入大文件又在后续层删除——文件仍存在于该层中，只是被标记为“不可见”，最终镜像体积不会减小
- 私有 Registry 可启用 GC（garbage collection）策略定期清理无引用的层，而 Docker Hub 对免费账户不提供手动 GC，需依赖自动清理逻辑
