可靠获取Docker镜像真实digest和架构信息需查registry或用buildx：docker buildx imagetools inspect nginx:alpine自动展开manifest list并显示各架构子项；docker inspect --format='{{index .RepoDigests 0}}'仅当以digest拉取过才有效；registry返回的manifest digest（非本地image ID）才是权威标识。
怎么看一个 Docker 镜像的真实 digest 和架构信息？
镜像 docker pull nginx:alpine 看似简单，但实际拉下来的可能是多架构 manifest 中的某一个变体。直接 docker images 只显示 tag 和 size，不反映底层 digest 或平台信息。
- 用
docker inspect --format='{{.RepoDigests}}' nginx:alpine查不到 digest？说明该镜像本地没被以 digest 方式拉取过（tag 拉取不会自动写入 RepoDigests） - 真正可靠的方式是查 registry：先
docker pull --platform linux/amd64 nginx:alpine，再运行docker inspect --format='{{index .RepoDigests 0}}' nginx:alpine - 或者跳过本地，直接用
curl -H "Accept: application/vnd.docker.distribution.manifest.v2+json" https://registry-1.docker.io/v2/library/nginx/manifests/alpine（需先获取 token）——但注意：这个请求返回的是 manifest list（v2 schema 2），不是单个镜像 blob
Manifest list 和 image manifest 到底怎么区分？
当你看到 {"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.list.v2+json"}，这就是 manifest list；而 "mediaType":"application/vnd.docker.container.image.v1+json" 才是具体某个架构下的 image manifest。
- manifest list 是“目录”，里面含多个
manifests数组项，每项带platform.os、platform.architecture、digest - image manifest 是“文件详情”，包含
layers、configdigest、schemaVersion等，才是最终构建容器的基础 -
docker buildx imagetools inspect nginx:alpine会自动递归展开 manifest list 并展示所有子项，比手查 curl 清晰得多
为什么 docker push 后 registry 返回的 digest 和本地 docker images -q 不一致？
因为 docker images -q 输出的是本地 image ID（即 config blob 的 sha256），而 registry 返回的 digest 是 manifest 的 digest（schema 2 的完整 JSON 内容哈希）。
- 两者算法不同：image ID 是 config 文件的 digest；manifest digest 是整个 manifest JSON 字符串（含换行缩进）的 sha256
- 哪怕 config 和 layers 完全一样，只要 manifest 里
mediaType字段值或字段顺序稍有差异，digest 就不同 - 多平台镜像 push 后，registry 返回的 digest 总是 manifest list 的 digest，不是任一子镜像的 digest —— 这点常被误认为“push 失败”或“覆盖出错”
如何安全地复用已有 layer，又不污染 manifest 结构？
用 docker build --cache-from 或 BuildKit 的 cache-to 能复用 layer，但不会改变原始 manifest；真要改 manifest（比如合并多平台、删掉不用的 arch），必须用工具重写。
-
docker buildx imagetools create支持拼装多个 digest 成新 manifest list，但要求每个输入都是已推送到 registry 的完整镜像（不能是本地未 push 的 image ID） - 不要用
docker save | docker load来中转 multi-arch 镜像：它只保存当前平台匹配的那个子镜像，manifest list 信息彻底丢失 - CI 中若需固定 digest，务必在 push 后立刻记录 registry 返回的 manifest digest，而不是依赖本地
docker images或docker inspect
manifest 的 digest 不是“镜像指纹”的终点，而是起点——它指向的 config 和 layers 才决定行为一致性。很多人卡在 manifest list 层就停了，其实关键逻辑在下一层的 image manifest 和 config.json 里。
