在我的电脑上，在一个窗口中，假设一个大型docker构建正在进行中（大约30层）。当构建正在进行时（比如它已经到达第20层），在另一个窗口中，假设我运行 docker image prune -a -f (目标是删除悬空和未使用的图像)，那么正在构建的图层是否会被认为是悬空而被删除导致构建失败？这是决定性的行为吗？
该 docker image prune -a -f 命令将删除所有图片，包括被标记的图片，所以不只是删除那些悬空的图片（这是 -a 选项）。) 在这个过程中，很可能会出现竞赛条件，这取决于prune命令扫描使用中的映像时，构建体所处的位置。如果当前的构建是在一个 RUN 步骤并使用图像，那么修剪应该跳过该图像使用的所有图层。
如果你是在 RUN 步骤，当prune命令寻找要删除的映像时，它可能会尝试删除在您的构建中被用作父级的映像。如果在删除过程中，该映像又被使用，那么很可能会导致prune出错。然而，如果修剪删除了构建预期要扩展的父图像，它也可能会导致构建中的错误。
通常情况下，我建议不要进行修剪，因为你希望被清理的映像会包括那些在构建中被积极使用的映像。你会导致构建需要更长的时间，因为被删除的映像是针对下载的，而且你可能会导致注册表和其他节点上使用更多的空间拉动图像，如果层被重新创建，而不是重新使用以前构建的缓存层。
对于一个活跃的构建服务器，使用内置垃圾收集功能的buildkit是一个更好的选择。垃圾回收是根据图层的大小来确定图层的使用时间，而不是最初创建的时间，因此你可以为你的映像构建分配特定数量的磁盘。而且由于buildkit运行在containerd上，而不是直接运行在docker引擎上，所以缓存本身不会与docker镜像混合，你可以修剪镜像而不影响构建缓存。这些垃圾收集选项有一个例子，在 我的DockerCon演讲.