直接用镜像digest（如sha256:9f86d081...）拉取部署可精准锁定构建产物，因其是manifest全文的不可变sha256哈希；而tag仅为可覆盖指针，易导致环境不一致、回溯困难与协作冲突。
直接用镜像的 content-addressable digest（如 sha256:9f86d081...）拉取和部署，就能精准锁定某次构建产物——因为 digest 是由镜像 manifest 全文计算出的唯一哈希，内容不变则 digest 不变，内容一变 digest 必然不同。
为什么 tag 无法锁定历史版本
tag 只是 registry 上一个可被反复覆盖的指针。比如 myapp:v1.2 昨天指向安全构建，今天被 CI 脚本重新推送后，可能已替换成含漏洞或未测试的版本。同一 tag 下，docker images 显示的 IMAGE ID 可能不同，各环境拉取的实际 rootfs 也可能不一致。
- 故障回溯时无法确认运行的是哪次构建产物，只能靠日志时间点“猜”
- 审计时无法证明“这个生产镜像确实等于当时通过 QA 的那个”
- 多团队协作中，tag 命名冲突或误覆盖极易发生
如何提取并固化 digest
构建完成即刻获取 digest，并将其写入部署配置，确保后续所有环节都基于该值操作：
- 执行
docker inspect --format='{{index .RepoDigests 0}}' <image-id></image-id>提取完整 digest 字符串（如myapp@sha256:abc123...） - 将 digest 写入 Helm values、Kustomize config 或 Kubernetes YAML 的
image:字段，格式为registry.example.com/myapp@sha256:abc123... - 在 CI 脚本中禁用
docker push myapp:latest，只允许带语义化版本或 digest 的推送（如docker push myapp:v1.2.3和docker push myapp@sha256:abc123...）
部署与运行时如何验证锁定效果
使用 digest 后，拉取、校验、启动全过程均绑定原始内容：
-
docker pull myapp@sha256:abc123...会强制校验 Registry 返回的Docker-Content-Digest响应头是否匹配，不一致则中止 - 容器启动前，Docker 会按 manifest 中 layer chainID 顺序叠加 rootfs，并交叉验证 config.json 中记录的
rootfs.diff_ids，确保文件系统未被篡改 - Kubernetes Pod 状态中
imageID字段显示的就是该 digest，可直接比对集群中实际运行的镜像指纹
配合签名增强可信度
digest 保证“内容没被改”，但不保证“是谁发的”。启用 Docker Content Trust（DCT）可补全身份验证：
- 设置
DOCKER_CONTENT_TRUST=1，所有pull操作自动校验签名有效性及与 digest 的绑定关系 - 未签名、签名过期或签名公钥不匹配的镜像会被拒绝拉取，即使 digest 正确
- 私有 Registry 需对接 Notary；主流云服务（ECR、ACR、Docker Hub）已原生支持
