Docker 构建上下文过大导致 send 慢，最直接的处理方法是在项目根目录创建 `.dockerignore` 文件，排除 `node_modules`、`.git` 等无需构建的大体积目录。适用场景为本地构建或 CI 流程中上下文传输耗时过长的情况，风险在于误排除构建必需文件导致构建失败。

命令速用版

以下命令用于开启详细构建日志，观察上下文传输耗时：

docker build `--progress`=plain -t my-image .

若使用 Docker Compose，可结合以下命令强制重建并查看日志：

docker-compose up `--build` `--progress`=plain

为什么会这样

Docker 构建慢的核心原因是客户端会将构建命令所在目录的全部文件打包发送给守护进程。默认情况下，Docker 会将当前路径下的所有文件递归发送到 Docker 守护进程，若项目根目录包含 `node_modules`、`logs` 或 `.git` 等大体积文件夹，将显著拖慢构建起始阶段。构建上下文（Build Context）会将主机上的所有文件递归发送到 Docker 守护进程，若不加控制，可能传输大量无用或敏感文件，影响构建效率与安全性。

分步处理

第一步：创建忽略文件。在项目根目录（与 Dockerfile 同级）创建名为 `.dockerignore` 的文件，其语法类似 `.gitignore`。

第二步：配置排除规则。在文件中添加无需构建的路径，常见配置如下：

# 排除版本控制文件
.git/
.gitignore
# 排除构建产物
node_modules/
dist/
# 排除日志和缓存
*.log
.cache/

第三步：执行构建。运行构建命令，观察终端输出的上下文大小提示。若配置生效，发送的文件数量会显著减少。

怎么验证是否生效

构建开始时，Docker 客户端会输出类似"Sending build context to Docker daemon X MB"的提示。优化前该数值可能达到数百 MB，优化后应降至较小数值。部分优化案例显示上下文可从数百 MB 降至十余 MB，尤其在远程构建或 CI 环境中效果显著。同时，使用 `--progress=plain` 参数可确保以文本形式输出所有步骤的开始/结束时间与资源消耗，便于对比传输阶段耗时。

常见坑

误排除必需文件：配置 `.dockerignore` 时需确保 Dockerfile 本身及构建所需的源代码未被排除，否则会导致构建失败。忽略文件语法错误：`.dockerignore` 支持通配符，但需注意路径写法，例如 `node_modules/` 表示目录，`*.log` 表示文件。构建缓存失效：若 Dockerfile 中 COPY 指令包含变动频繁的文件，可能导致后续层缓存失效，即使上下文已瘦身，构建速度仍可能受影响。

常见问题

docker-compose up `--build` 也会受上下文影响吗？

会受影响。Docker Compose 在执行 up `--build` 时，会针对每个标记了 build 指令的服务触发本地镜像构建流程，同样遵循 Docker 构建上下文传输机制。

配置了 .dockerignore 为什么构建还是慢？

可能原因包括构建缓存未命中或基础镜像拉取缓慢。若每一层均重新构建，提示构建缓存未生效，需检查 Dockerfile 是否合理利用缓存机制。

多阶段构建能解决上下文大的问题吗？

多阶段构建主要解决镜像体积膨胀问题，但配合 .dockerignore 使用可进一步减少上下文影响。多阶段构建允许只将必要产物复制到最终镜像，确保最终镜像不包含构建依赖。

参考来源

• 5 个实用技巧！优化 gh_mirrors/do/dockerfiles 镜像构建上下文大小
• 为什么你的 Docker 构建越来越慢？(真相藏在.dockerignore 里)
• 构建速度慢？你可能忽略了 Docker Next-gen 上下文的这 3 个关键点
• 告别缓慢构建和超大镜像,.dockerignore 你真的用对了吗？
• Docker Buildx 构建缓慢？通过日志发现性能杀手的 4 步法
• 揭秘 Docker Compose up `--build`:为何每次构建都慢如蜗牛？