Docker BuildKit构建：--mount挂载大文件是否传输至Docker守护进程

1、超大文件是否会被发送至Docker守护进程？--mount参数处理大文件是否具备优势？ #

只要你要挂载的large_dir_or_file位于执行构建命令时指定的上下文路径（即命令末尾.对应的当前工作目录）下，它依然会被发送到Docker守护进程。

Docker Buildx启动构建的首个步骤就是扫描、打包整个指定构建上下文，传输给构建后端（本地守护进程或远程构建节点），这一步的逻辑和后续Dockerfile里使用的文件处理指令无关：只要文件在上下文目录内，就会被纳入传输范围。

使用RUN --mount=type=bind处理构建期大文件有明确优势：

• 大文件仅以挂载形式存在于构建阶段的临时运行容器中，不会被写入任何镜像层。如果换用COPY/ADD指令将大文件复制到构建环境，哪怕后续在RUN指令中手动删除该文件，它仍会残留在之前提交的镜像层中，直接导致最终镜像体积异常增大，这是非常常见的构建坑点
• 无需额外编写命令清理构建期临时使用的大文件，减少不必要的镜像层数量
• 示例中配置了readonly参数，挂载为只读模式，构建过程不会意外修改本地的源文件

如果要完全省去大文件的上下文传输开销，可以将大文件移出构建上下文目录，配置Buildx允许挂载上下文外的宿主机绝对路径，此时大文件不会走上下文打包传输流程，会被直接挂载进构建容器。

2、若Docker构建上下文与Docker守护进程部署在同一台机器上，是否所有上下文文件仍会被发送/复制到Docker守护进程可访问的路径下？ #

默认配置下仍然会执行复制操作。
哪怕在本机直接执行构建命令，Docker客户端依然会遍历整个上下文目录、打包为tar归档，通过本地Unix套接字传递给Docker守护进程，守护进程会将归档解压到自身专属的临时工作目录，后续所有构建操作都基于这个副本执行，不会直接读取本地工作目录的原文件。这个设计是为了避免构建过程中本地文件被改动，导致构建结果不可复现。
只有手动配置Buildx启用宿主机路径直通挂载、且对应文件不在构建上下文范围内时，才会跳过复制步骤，这不属于默认构建行为。

内容的提问来源于stack exchange，提问作者Daniel