docker镜像推送与拉取通过分层哈希机制只传输差异层，显著降低带宽占用；推送时仅上传registry缺失层，拉取时跳过本地已有层，配合固定基础镜像标签、sha锁定及仓库级增量同步进一步提升复用率。
docker 镜像推送与拉取之所以能显著降低网络带宽占用，核心在于其底层的分层传输机制——每一层都通过内容哈希唯一标识，服务端和客户端各自维护层索引，只传输缺失或变更的层，而非整个镜像。
只传差异层，不传整镜像
当推送一个新版本镜像（如 app:v1.2.0）时，Docker 客户端会先向远程 Registry 发送各层的 SHA256 哈希列表；Registry 返回已存在的层 ID；客户端仅上传那些 Registry 没有的层。例如，基础层 alpine:latest 和通用依赖层若已在 Registry 中，就完全跳过上传。
- 同一基础镜像构建的多个应用镜像（如 web、api、worker）共享底层，上传总量远小于累加体积
- 更新镜像时，仅 RUN 或 COPY 指令产生的新层需上传，其余只读层复用
- 实测显示：连续发布 5 个微版本，平均单次上传量可降至完整镜像的 8%–22%
拉取时自动跳过本地已有层
执行 docker pull 时，客户端同样比对本地镜像层哈希与 Registry 记录。若某层（如 glibc 更新层或 Python 运行时层）已存在，直接复用，不发起下载请求。
- CI/CD 流水线中，不同 Job 共享宿主机 Docker 存储目录时，重复拉取基础镜像几乎为零开销
- 跨项目部署时，只要共用相同 base 镜像（如 python:3.11-slim），首次拉取后，后续项目仅下载业务代码层
- 企业内网搭配 Harbor 缓存代理后，90%+ 的拉取请求命中本地层缓存，外网带宽节省可达 70% 以上
配合标签策略强化层复用
固定基础镜像标签（如用 python:3.11.9-slim 替代 python:3.11-slim）能避免因上游基础镜像滚动更新导致的层哈希变化，防止“看似小改、实则全传”问题。
- 禁止在生产构建中使用 latest 标签，确保层稳定性
- 按语义化版本管理镜像（v1.2.0、v1.2.1），使 patch 版本大概率复用前序构建层
- 在 Dockerfile 开头显式指定基础镜像 SHA（如 FROM python@sha256:abc123...），彻底锁定层内容
启用镜像仓库级增量同步能力
主流企业级 Registry（Harbor、Nexus、AWS ECR）均支持镜像同步时的层级去重。跨地域同步镜像仓库时，不是复制整个镜像包，而是同步层元数据 + 差异层 Blob。
- 例如从华东区 Harbor 同步到华北区，若 87% 的层已存在，仅传输剩余 13% 层及 manifest
- 结合 registry 的 GC 策略定期清理孤立层，避免历史冗余层拖慢同步效率
- 开启 registry 的 blob mount 功能（Docker v2 API 支持），允许客户端直接引用远端已存在层，免上传
