Docker镜像通过SHA256 digest实现物理完整性验证：解压tar包后比对manifest.json中各层digest与blobs目录下文件实际哈希，不一致即表明存储损坏；需导出时存档原始哈希作可信基线，加载前强制校验，并联动SMART与文件系统工具闭环定位硬件故障。
Docker 镜像的底层内容寻址机制天然适配物理完整性验证——它不靠文件名或路径，而是依赖每层内容生成的唯一 SHA256 指纹（即 digest），只要内容有一字改动或存储介质发生静默损坏（如磁盘坏块、SSD 写失败），哈希值就会彻底改变。这种“内容即地址”的设计，让校验不再依赖外部记录，而能直接从镜像自身结构出发，精准定位受损层。
用 manifest.json 提取所有 layer digest 并逐层比对实际哈希
镜像 tar 包解压后，其结构固定为 blobs/sha256/ 目录下存放压缩后的各层数据，每个文件名就是该层的 digest；而 manifest.json 中明确列出每一层对应的 digest 字段。二者应严格一致：
- 解压镜像：
tar -xvf myapp.tar -C /tmp/check - 解析 manifest 获取预期 digest 列表：
jq -r '.[0].Layers[]' /tmp/check/manifest.json - 计算 blobs 下每个文件的实际哈希：
find /tmp/check/blobs/sha256/ -type f -exec sha256sum {} \; | cut -d' ' -f1 - 用脚本比对两组哈希，任一不匹配即说明该层所在存储位置已损坏（例如对应磁盘扇区失效）
导出时立即存档原始哈希，建立可信基线
不要等出问题再回头查。每次执行 docker save 后，立刻计算并保存 tar 文件本身与内部 manifest 的哈希：
-
docker save -o app.tar myapp:latest -
sha256sum app.tar > app.tar.sha256 -
docker run --rm -v $(pwd):/host alpine sha256sum /host/app.tar | cut -d' ' -f1 > app-manifest-digest.txt（用于后续快速回溯）
这些哈希文件应和 tar 包一同备份，并隔离存储（如不同磁盘或对象存储），避免同源损坏导致基线失真。
在加载前强制触发校验，堵住损坏扩散入口docker load 命令本身不做完整层校验，它信任 tar 包结构。必须在 load 之前插入校验步骤：
- 用
skopeo inspect docker-archive:app.tar快速查看 manifest 是否可解析、digest 是否格式合法 - 若通过，再执行前述 blobs 层级比对
- 校验失败时中断流程，不执行
docker load，防止损坏层写入/var/lib/docker/image/overlay2/导致后续容器运行异常或污染本地镜像缓存
结合存储路径监控，把校验结果反馈给底层健康系统
单次校验只是快照，需联动存储层形成闭环：
- 当某层哈希不匹配时，记录其 digest 和对应 blob 文件路径，反向推断可能出问题的磁盘分区（如
/var/lib/docker所在的/dev/sdb1） - 自动触发
smartctl -a /dev/sdb检查 SMART 状态，重点关注Reallocated_Sector_Ct、UDMA_CRC_Error_Count - 对该分区运行
e2fsck -n /dev/sdb1（ext4）或xfs_repair -n /dev/sdb1（XFS）预检文件系统一致性 - 若确认存在硬件风险，立即将该节点从镜像仓库集群中剔除，并告警运维人员更换磁盘
不复杂但容易忽略
