docker通过diffid和chainid实现内容寻址：diffid是层原始内容的sha256哈希，确保“改了什么”真实；chainid由diffid及上层chainid推导，确保“位置不可变”，二者共同支撑镜像复用、校验与防篡改。
直接看镜像层的 SHA256 值，就能看清 Docker 是怎么“认内容不认名字”的——它不靠标签（比如 latest）找数据，而是靠每层内容生成的唯一哈希值定位、复用、校验。这种机制既是存储去重的基础，也是防篡改的底层防线。
看懂 diffID 和 chainID 这两个关键哈希
每个镜像层实际有两个 SHA256 值，作用不同但紧密关联：
- diffID：对层原始未压缩内容（tar 包）计算的 SHA256，代表“这一层到底改了什么”。内容一变，diffID 必然变。它是内容真实性的第一把尺子。
- chainID：由 diffID 推导而来，体现“这一层在整条链里的位置”。第一层 chainID = 第一层 diffID；第二层 chainID = SHA256(第一层 chainID + 第二层 diffID)，依此类推。它确保层顺序不可调换、不可插入或删除。
这两个值都写在镜像 manifest 和 config blob 中，Docker 启动、拉取、构建时全靠它们精准索引和验证。
通过命令直观查看各层哈希
不用翻文件、不依赖外部工具，本地就能查到真实层结构：
-
docker image inspect <image> --format='{{json .RootFS.Layers}}'</image>：输出一串 sha256 开头的层摘要列表，这就是 chainID 序列，对应最终挂载顺序。 -
docker history <image></image>：显示每层的大小、创建指令和 layer ID（即 chainID 缩写），帮你快速对应 Dockerfile 步骤。 - 想确认某层是否被复用？运行
ls -l /var/lib/docker/image/overlay2/layerdb/sha256/，目录名就是 chainID；存在即说明该层已在本地，后续镜像构建或拉取会直接跳过下载。
为什么相同内容一定复用同一层
内容寻址（CAS）不是策略，是强制行为：
- Docker 构建时，对 RUN、COPY 等指令产生的文件系统变更做完整快照，再算 diffID —— 文件内容、权限、时间戳、甚至空格数量都影响结果。
- 只要两次构建中某步产出完全一致（比如都执行
RUN pip install numpy==1.24.0且依赖树完全相同），diffID 就一样，chainID 也一样，Docker 就只存一份物理数据。 - 跨镜像共享也由此实现：多个服务镜像都基于
python:3.11-slim，它们的第一层（基础 OS）chainID 相同，磁盘上只存一次。
校验和如何支撑安全与可复现
SHA256 不只是“存个指纹”，它驱动着整个可信链条：
- 拉取时自动校验：Docker 下载 layer tar.gz 后，立刻解压并重算 diffID，和 manifest 中声明的比对；不匹配就中断，报错如
invalid diffID for layer 0。 - 运行时仍有效：容器启动前，Docker 会按 manifest 中的 chainID 列表组装 rootfs，并用 config blob 再次核验最终文件系统结构，防止运行中被篡改。
- 可复现的关键：固定基础镜像 tag 不够，必须固定所有依赖版本（pip、apt）、禁用缓存（
--no-cache）、使用完整 digest 拉取（docker pull @sha256:...），才能保证每次构建出的 diffID 完全一致。
