Docker Compose build关闭缓存重建镜像

Docker Compose关闭构建缓存的直接命令是docker compose build --no-cache 服务名。如果还要尝试更新Dockerfile引用的基础镜像，再加--pull。构建成功后还需要让服务容器使用构建结果；单独执行build不会把已经运行的容器替换成新镜像。

例如，文件明明已经修改，容器里却读到旧文本。这时要分别检查保存位置、构建上下文、构建缓存和容器替换。本文用一个只读取文本的独立示例排除干扰，再结合Docker Desktop的Builds与Containers入口查看状态。所有图片均为原创界面说明图，具体布局可能随版本变化。

Compose build官方地址：https://docs.docker.com/reference/cli/docker/compose/build/

步骤1：确认构建入口与示例文件

在独立目录中，用编辑器“文件 → 新建文件 → 另存为”分别保存compose.yaml、Dockerfile和message.txt。先在message.txt写入before-rebuild并保存。它们必须位于同一目录；compose.yaml指定的context为当前目录，COPY读取的是构建上下文中的文件，而不是随意一个编辑器窗口的同名文件。

name: compose-cache-lab
services:
  demo:
    # build定义本地构建入口，image指定构建后使用的本地标签。
    build:
      context: .
      dockerfile: Dockerfile
    image: compose-cache-lab-demo:local

# 演示只复制文本文件，不安装依赖，也不发布网络服务。
FROM alpine:3.23
WORKDIR /opt/demo
COPY message.txt ./message.txt
# 保持演示容器运行一小时，便于后续exec读取文件。
CMD ["sleep", "3600"]

该示例使用Docker官方文档中出现的Alpine 3.23基础镜像标签；这是演示选择，不是推荐永远固定此版本。没有端口映射和数据卷，避免宿主机文件挂载遮住镜像内文件。确保Docker Desktop引擎已经运行，然后在该演示目录执行：

# 在示例目录先查看生效配置，避免构建了另一份文件。
docker compose config
# 建立最初镜像和容器。
docker compose build demo
docker compose up -d --no-build demo
docker compose exec -T demo cat /opt/demo/message.txt

首次读取应看到before-rebuild。再进入Docker Desktop左侧Builds，在构建列表中找到本次对应的构建记录；必要时先确认当前选中的builder与命令使用的一致。可以点击记录进入详情。若首次构建就失败，先处理Dockerfile路径、镜像拉取或文件缺失，不要把所有失败都归因于缓存。

步骤2：关闭构建缓存并查看构建记录

回到message.txt，把内容改为after-rebuild并通过编辑器“文件 → 保存”落盘。然后在同一个示例目录执行下面的第一条命令。这个例子里的COPY内容变化通常已经足以触发相关层重建；这里显式关闭缓存，是为了演示排查时怎样排除层复用因素。

# 修改message.txt并保存后，只重建demo服务，跳过构建层缓存。
docker compose build --no-cache demo
# 若目标还包括更新基础镜像，改用这一条，而不是重复执行两条。
# docker compose build --no-cache --pull demo

--no-cache不是全局删除缓存，也不保证每次联网下载基础镜像。--pull负责尝试取得引用的新镜像内容；若FROM固定到了摘要，它也不会自动换成另一个摘要。遇到代理、网络或仓库认证错误，应按实际报错处理，不要因为加了pull就将失败称为缓存错误。

在Docker Desktop依次进入Builds → 本次构建记录 → Info，查看构建参数、依赖与结果。需要判断哪一步复用时，打开Logs查看具体记录；构建失败时还可查看Error中的定位信息。界面用于观察这次命令产生的记录，本文不假设任何版本都有一个名为“关闭缓存”的GUI开关。

本步完成的判断是构建命令成功退出并产生可用镜像。无缓存重建不要求镜像ID必然变化：输入和构建结果相同，内容寻址的结果仍可能相同。不能仅凭“ID没变”认定no-cache失效。

步骤3：重建容器并读取镜像内文件

即使镜像已经构建好，之前启动的容器也仍然来自旧镜像。现在使用下面的命令替换独立示例的demo容器，再读取文件。--no-build避免此处重新构建，--pull never避免把刚构建的本地标签换成拉取结果，--force-recreate明确要求重新创建。

# 构建成功后替换演示容器，明确禁止这一阶段再次构建或拉取。
docker compose up -d --no-build --pull never --force-recreate demo
docker compose exec -T demo cat /opt/demo/message.txt
# 核对当前服务状态及其镜像；不要只看镜像标签文字。
docker compose ps
docker compose images demo

进入Docker DesktopContainers → compose-cache-lab → demo，查看服务已经重新运行；随后以命令读取的after-rebuild作为应用内容判断。运行状态只说明容器启动，不说明文件内容正确。本例的sleep是一小时演示占位，时间结束后退出是预期行为。

不要把restart当作替代方案。重启已有容器与用构建后的镜像创建新容器是不同操作。正式项目重建会影响服务连续性，应按自身发布流程安排，而不是在生产服务中直接套用演示命令。

设置仍不生效时的排查与回退

只有image、没有build的服务能这样重建吗？没有本地构建定义，就不存在本文这条Dockerfile构建路径。应先判断服务是拉取现成镜像还是自行构建；不要给纯image服务添加无意义的no-cache参数期待源码变化。

已经no-cache，依赖为什么还是旧的？重新执行安装指令不会解除版本约束。锁文件指定旧版本时，再执行也是旧版本；使用RUN的cache mount时，还要单独考虑包管理器缓存目录，不能把no-cache理解成所有缓存的统一清空按钮。

需要先执行prune吗？为本次构建跳过层缓存通常不需要先清理其他项目的缓存。全局清理会影响其他构建，也无法修复错误的context或被挂载覆盖的目录。先按本例明确服务范围，保留可复现输入。

怎样恢复正常构建？命令行no-cache只作用于当次构建，下一次省略即可恢复常规缓存使用；若把no_cache写入了Compose的build配置，需要移除该配置。先恢复正确源文件再构建：

# 调整源文件或配置后，回到常规缓存构建与启动。
docker compose build demo
docker compose up -d --no-build --pull never demo

这只是重新构建当前输入，不等于自动回滚。要可靠回退到上一版，应在替换前保留独立的旧镜像标签或摘要及匹配配置，不要让同一个local标签覆盖掉唯一可用版本。

Docker Desktop构建记录参考：https://docs.docker.com/desktop/use-desktop/builds/

构建缓存规则参考：https://docs.docker.com/build/cache/invalidation/