哈希值确保数据完整性：diffid校验每层内容，digest锁定整镜像唯一状态，拉取时自动比对manifest、layer及rootfs，启用dct后叠加数字签名实现来源可信。
靠哈希值本身就能确保数据完整性——内容一变，哈希就变，这是内容寻址机制最直接的保障方式。
每层都有不可伪造的 diffID
镜像每一层在构建完成后，Docker 会对其原始文件内容（tar 包解压后的完整目录树）计算 SHA256，生成 diffID。这个值只取决于该层实际修改了哪些文件、内容是否一致。哪怕只是改了一个空格，diffID 就完全不同。
- diffID 是校验 layer 内容真实性的第一道关卡
- 拉取时，Docker 下载 layer 数据后，会本地重新计算 diffID，并与 manifest 中声明的值比对
- 不一致则报错中断，拒绝组装该镜像
整镜像靠 digest 锁定唯一状态
manifest 文件描述了整个镜像的结构：包含哪些 layer 的 chainID、config blob 的哈希、架构信息等。Docker 对这个 JSON 文件整体做 SHA256 计算，得到镜像的 digest（如 sha256:abc123...）。它才是镜像的“最终身份证”。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- tag（如 latest、v2.0）只是指向 digest 的软链接，可被覆盖；digest 一旦生成，永远不变
- 用
docker pull nginx@sha256:abc123...拉取，跳过 tag，直取确定内容 - registry 返回的 HTTP 响应头
Docker-Content-Digest与客户端计算值必须一致，否则拉取失败
运行前再验 rootfs 组装结果
光校验各层和 manifest 还不够。Docker 在容器启动前，会按 manifest 中的 layer 列表和 config，把所有 layer 按 chainID 顺序叠加，再重新计算最终 rootfs 的哈希（类似构建时的 chainID 推导），并与 config blob 中记录的 rootfs.diff_ids 和 rootfs.type 交叉验证。
- 这一步防止 layer 被恶意替换或顺序错乱
- 也确保 config 描述的运行时参数（如 Entrypoint、Env）与实际组装出的文件系统匹配
- 即使某层 diffID 正确，若被插入到错误位置，chainID 链就会断裂，验证失败
配合内容信任（DCT）增加来源可信度
digest 解决“内容没被篡改”，但不解决“这内容是谁发布的”。启用 Docker Content Trust 后，manifest 会被签名，Notary 服务会对 digest 做数字签名并托管公钥。
- 设置
DOCKER_CONTENT_TRUST=1后，所有pull和push自动触发签名检查 - 只有签名有效且 digest 匹配的镜像才允许运行
- 相当于在完整性基础上，加了一层发布者身份认证
