正如您中提到的问题 20131 https://github.com/docker/docker/issues/20131#issuecomment-182294926，这可能是新的结果docker 1.10 内容寻址迁移 https://github.com/docker/docker/wiki/Engine-v1.10.0-content-addressability-migration
来自Docker 博客文章 https://blog.docker.com/2016/01/docker-1-10-rc/:
从 v1.10 开始，我们彻底改变了 Docker 在磁盘上处理镜像数据的方式。
以前，每个图像和图层都使用随机分配的 UUID。
在 1.10 中，我们基于图像和图层数据的安全散列，使用 ID 实现了内容可寻址方法。
因此塔吉兹塔 https://github.com/thaJeztah评论：
我认为这是预料之中的；内容寻址存储不再使用“父”图像将图像层链接在一起。
新拉取的图像也不再显示中间图像（这些“丢失”的图像将仅显示主机上存在但已迁移到新存储的图像）
2016 年 6 月更新（3 个月后）
奈杰尔·布朗 https://github.com/nbrownuk有一篇关于那些“丢失”图像的详细文章。
解释 Docker 镜像 ID http://www.windsock.io/explaining-docker-image-ids/
层或“差异”是在 Docker 映像构建过程中创建的，并在容器中运行命令时产生，从而生成新的或修改的文件和目录。
这些新的或修改的文件和目录被“提交”为新层。
历史上（Docker v1.10 之前），每次提交操作创建一个新层时，Docker 也会创建一个相应的镜像，该镜像由随机生成的 256 位 UUID 进行标识，通常称为镜像 ID
变革的主要推动力之一来自缺乏检测图像内容在推送到注册表或从注册表中拉取期间是否被篡改的方法， 如那个码头工人中心 https://hub.docker.com/。这导致强烈的批评 https://github.com/docker/docker/issues/9719来自整个社区，并导致了一系列变化，最终产生了内容可寻址 ID。
从 Docker v1.10 开始，通常，图像和图层不再是同义词.
相反，映像直接引用最终贡献于派生容器的文件系统的一个或多个层。
现在通过摘要来标识层，其形式为算法：十六进制；
Docker 镜像现在由一个配置对象组成，该对象（除其他外）包含层摘要的有序列表，这使得 Docker 引擎能够参考层摘要而不是父镜像来组装容器的文件系统。
因此，当从注册表中提取 Docker 映像并使用 docker History 命令显示其内容时，输出将提供类似于以下内容的内容：
$ docker history swarm
IMAGE CREATED CREATED BY SIZE COMMENT
c54bba046158 9 days ago /bin/sh -c #(nop) CMD ["--help"] 0 B
<missing> 9 days ago /bin/sh -c #(nop) ENTRYPOINT &{["/swarm"]} 0 B
<missing> 9 days ago /bin/sh -c #(nop) VOLUME [/.swarm] 0 B
<missing> 9 days ago /bin/sh -c #(nop) EXPOSE 2375/tcp 0 B
<missing> 9 days ago /bin/sh -c #(nop) ENV SWARM_HOST=:2375 0 B
<missing> 9 days ago /bin/sh -c #(nop) COPY dir:b76b2255a3b423981a 0 B
<missing> 9 days ago /bin/sh -c #(nop) COPY file:5acf949e76228329d 277.2 kB
<missing> 9 days ago /bin/sh -c #(nop) COPY file:a2157cec2320f541a 19.06 MB
The <missing>值在IMAGE除了图像的一层之外的所有层的场，具有误导性并且有点不幸。它传达了错误的建议，但是没有错误，因为图层不再与相应的图像和 ID 同义.
我认为将该字段留空会更合适.
此外，图像 ID 似乎与最上层相关联，但实际上，图像 ID 不“属于”任何层。相反，这些层共同属于映像，并提供其文件系统定义。
但是（本地与远程图像）：
Docker 主机上本地构建的镜像的处理方式略有不同.
本地构建的图像的通用内容保持不变 - 它是一个包含配置项的配置对象，包括层摘要的有序列表。
但是，当在本地 Docker 主机上构建映像期间提交层时，会同时创建“中间”映像.
就像所有其他图像一样，它有一个配置项，它是要合并为图像一部分的层摘要的列表，并且其 ID 或摘要包含配置对象的哈希值。中间图像没有名称标记，但它们确实有一个“父”键，其中包含父图像的 ID。
中间图像和对父图像的引用的目的是方便使用Docker的构建缓存 http://thenewstack.io/understanding-the-docker-cache-for-faster-builds/.
$ docker history jbloggs/my_image:latest
IMAGE CREATED CREATED BY SIZE COMMENT
26cca5b0c787 52 seconds ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "/bin/b 0 B
97e47fb9e0a6 52 seconds ago /bin/sh -c apt-get update && apt-get inst 16.98 MB
1742affe03b5 13 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
<missing> 13 days ago /bin/sh -c #(nop) ADD file:5d8521419ad6cfb695 125.1 MB
在此示例中，顶部两层是在本地映像构建期间创建的，而底层来自构建的基础映像（例如Dockerfile指令FROM debian https://docs.docker.com/engine/reference/builder/#from).
我们可以使用docker inspect命令查看与图像关联的图层摘要：
The docker history命令显示图像有四层，但是docker inspect建议仅三层。
这是因为两人CMD指令生成图像的元数据，不添加任何内容，因此“diff”为空。
摘要5f70bf18a08a是空层的 SHA256 哈希值，由相关的两个层共享。
当本地构建的镜像被推送到注册表时，只有叶镜像及其组成层被上传，并且随后由另一个 Docker 主机拉取不会产生任何中间父镜像.
这是因为，一旦通过注册表将映像提供给不同 Docker 主机上的其他潜在用户，它实际上就会变为只读，并且不再需要支持构建缓存的组件。
而不是图像 ID，<missing>被插入到历史输出中的适当位置。
Finally:
Docker 在 Docker 主机上用于层“差异”的摘要包含差异的 tar 存档内容的 sha256 哈希值。
在将层作为推送的一部分上传到注册表之前，会对其进行压缩以提高带宽效率。还创建清单来描述图像的内容，并且它包含压缩层内容的摘要。因此，清单中各层的摘要与未压缩状态下生成的摘要不同。
