Compose 添加 build 后仍拉取镜像：检查 pull_policy

基础 Compose 文件写了 image，开发覆盖文件增加了 build。本地 Dockerfile 明明已经修改，docker compose up -d 却仍拉取并启动仓库中的镜像。先查看合并结果里的 pull_policy：增加 build 不会自动删除基础文件的 image 和拉取策略。

这种配置曾出现在 Compose 2.6.1、Docker Engine 20.10.17 环境中。处理时应以当前工具实际生成的模型和现行策略为准，不把旧版本的讨论直接当成所有版本的行为承诺。

覆盖文件可能只增加了构建来源

下面用独立的开发标签说明合并关系，仓库地址和路径均为示例：

# compose.yaml
services:
  app:
    image: registry.example.com/team/app:dev-check
    pull_policy: always

# compose.dev.yaml
services:
  app:
    build:
      context: .
      dockerfile: docker/Dockerfile

合并后，app 同时具有 image、build 和 pull_policy: always。image 仍指定镜像名称，build 增加了本地构建配置，两者是不同属性。always 要求从仓库拉取，不能因为后一个文件包含 Dockerfile 路径，就认为仓库镜像已被排除。

用启动时同一组文件和项目参数检查：

docker compose -p app-dev -f compose.yaml -f compose.dev.yaml config

实际项目名和文件顺序需要保持一致；若脚本使用了更多覆盖文件，也要一并带上。输出可能展开密码或连接串，分享前脱敏。重点确认 image、构建上下文、Dockerfile 路径和 pull_policy，不要仅检查刚编辑的文件。

本地开发要明确选择构建策略

如果这个环境就是要使用本地 Dockerfile，可以在开发覆盖层显式设置：

services:
  app:
    build:
      context: .
      dockerfile: docker/Dockerfile
    pull_policy: build

当前 Compose 的 build 策略要求构建镜像，已有镜像也会重新构建；这不等于每一层都不使用缓存。保留 image 时，构建结果仍使用该镜像名称，因此示例采用开发检查标签，避免覆盖生产使用的标签。

若没有设置 pull_policy，同时存在 image 和 build 时，当前规则会先尝试拉取镜像，镜像在仓库或相应平台缓存中不可用时再构建。删掉 always 并不自动等于“以后每次优先本地构建”。never 也只是避免拉取、依赖已有镜像，不能代替明确的构建策略。

部署环境如果要求始终使用已审核的仓库产物，就应保留其拉取策略；不要为了让一次本地修改出现，顺带改变生产镜像来源。

核对运行的镜像，而不只看构建结束

在修改前保存完整配置和当前镜像摘要。应用开发配置会构建镜像，并可能重建服务、打断连接，应选择合适的环境和时间。重新运行同参数的 config，确认策略已变成 build；随后检查构建日志是否使用预期上下文与 Dockerfile，以及启动后的容器是否引用此次构建结果。

如果确实构建了新镜像，容器却仍表现为旧文件，继续检查挂载是否覆盖镜像内容。若旧内容来自数据卷，可转到命名卷遮住更新后的文件，不要直接删卷验证。

回退时恢复原文件与镜像来源，按原部署参数应用；需要恢复旧运行版本时使用先前保存的镜像摘要。清空全部构建缓存、删除数据卷都不属于这个拉取策略问题的必要操作。