digest是镜像内容的sha256哈希值，不可变且唯一绑定构建产物；tag仅为可被覆盖的可变指针，无法保证版本一致性。
Tag 是可变的别名，Digest 是不可变的内容指纹。
Tag 是可变指针，不是版本快照
Tag（比如 nginx:1.25 或 redis:latest）本质上是镜像仓库中一个可被重新指向的标签。维护者可以用 docker push --force 把同一个 tag 指向完全不同内容的新镜像。这意味着：
- 今天拉的
python:3.9和明天拉的，可能底层 digest 完全不同 - CI 构建在不同时间、不同机器上运行，可能因 tag 被覆盖而得到不一致结果
-
latest尤其危险——它不保证“最新稳定版”，只表示“最近一次打标的那个”
Digest 是内容哈希，天然防篡改
Digest（形如 sha256:abc123...）是对镜像完整内容（包括所有 layer 和 manifest）计算出的 SHA256 值。只要内容不变，digest 就不变；内容哪怕改一个字节，digest 必然变化。
- 它是内容寻址（content-addressable）的核心：相同 digest = 相同内容
- 拉取时用
nginx@sha256:4a92e7...，能 100% 确保拿到的是你审计/验证过的那个镜像 - 私有 registry、Harbor、Docker Hub 全部原生支持 digest 拉取和校验
Image ID 和 Digest 不是一回事
本地 docker images 显示的 IMAGE ID 是 Docker daemon 为本地镜像生成的标识，仅在当前宿主机有效；而 digest 是跨 registry、跨环境通用的权威内容标识。
-
docker images --digests只显示本地已缓存的 digest，可能为空或过期 - 真正可靠的 digest 必须从 registry 获取：用
curl查 API，或先pull再docker inspect xxx --format='{{index .RepoDigests 0}}' - 镜像推送后，registry 才会生成并返回最终 digest，本地构建时无法提前知道
什么时候该用哪个？
开发调试阶段用 tag 更方便；生产部署、CI/CD、安全审计必须用 digest。
- CI 流水线里禁止写死
:v1.2，应先查 digest，再 pull + run - Kubernetes PodSpec 中推荐用 digest 引用镜像，避免 runtime 意外拉到新版
- 合规场景（如等保、信创）要求镜像来源可追溯、内容可验证，digest 是唯一满足条件的依据
