直接比对镜像层的 SHA256 Digest 是实现极速增量分发最可靠方式，基于 OCI manifest 中 layer digest 列表做集合比对，相同 digest 层跳过传输，仅同步新增或变更层。
直接比对镜像层的 SHA256 摘要（Digest），是实现极速增量分发最可靠、最底层的方式。它不依赖标签（Tag），不比较文件内容，而是基于 OCI 镜像 manifest 中声明的 layer digest 列表做集合比对——相同 digest 的层可跳过传输，仅同步新增或变更的层。
为什么必须用 Digest，而不是 Tag 或文件 Diff
Digest 是内容寻址的唯一标识：同一层内容生成的 digest 必然一致，不同内容必然不同。而 Tag 是可变指针，ubuntu:22.04 今天和明天可能指向完全不同 digest 的镜像；文件级 diff（如 rsync）则无法复用 registry 已缓存的压缩层，还会破坏镜像完整性校验。
- manifest 中每个 layer 对应一个
digest字段，例如sha256:abc123... - 两个镜像的分歧，就是它们 manifest 中 layer digest 数组的差集
- registry 服务（如 Harbor、Docker Registry v2）本身按 digest 存储 blob，天然支持“查存在、传缺失”
实操四步：从比对到分发
以 v1.0 → v1.1 升级为例，全程无需拉取整镜像：
-
提取 digest 列表：用
skopeo inspect --raw或docker pull && docker image inspect --format='{{.RootFS.Layers}}'获取两镜像的 layer digest 序列 - 逐层比对顺序：从 base 层开始对齐，找到第一个 digest 不同的位置；其后所有层均视为需传输（因上层变更会改变下层的构建上下文）
-
构造最小传输集：筛选出目标环境 registry 中不存在的 digest（可通过 HEAD 请求
/v2/<repo>/blobs/<digest></digest></repo>验证） -
精准推送层：用
skopeo copy --src-filter或自定义脚本调用 registry API，只上传缺失 digest 对应的 layer blob
让增量真正“极速”的三个关键支撑
光有 digest 比对不够，还需基础设施配合：
- 代理型缓存（中小集群首选）：Harbor/Nexus 配置为 upstream mirror，Docker daemon 拉取时自动触发 digest 检查，只回源请求缺失层，本地组装返回
- P2P 协同（超大规模节点）：Kraken/Dragonfly 在节点间广播所需 digest，已有该层的节点直传数据块，绕过中心 registry 带宽瓶颈
- 预同步策略（多区域强一致）：CI 流水线末尾运行比对脚本，生成 layer 传输清单，再用 rsync 或 S3 sync 推送到各区域 registry，消除运行时网络不确定性
必须规避的常见失效点
很多所谓“增量”实际无效，根源在于破坏了 digest 复用链：
- 基础镜像用
latest或未锁定 digest，导致每次构建 base 层都变化，后续全层失效 - Dockerfile 中把
COPY node_modules放在早期，只要依赖更新，其后所有层缓存全崩 - 未启用 registry 的 gzip 压缩传输，客户端未发送
Accept-Encoding: gzip，导致层以原始大小传输
