image 与 build 怎么配合
image 指定镜像名与标签，可以是拉取来源，也可以是构建产物的命名；build 指定构建上下文与 Dockerfile。两者同时出现时，Compose 会先构建，再按 image 的名字给结果打标签，这样构建产物可以直接推送，编排里也能引用固定版本。
基本信息
| image | 镜像名与标签，如 registry.example.com/team/app/api:1.4.2 |
|---|---|
| build | context、dockerfile、args、target 等构建参数 |
| 共存行为 | 构建结果按 image 指定的名字打标签 |
| 只写 image | 直接拉取，不执行构建 |
| 构建参数 | args 会记录进镜像元数据，不要用来传凭据 |
典型使用场景
- 同一份文件兼顾开发与生产：开发环境保留 build，生产环境用覆盖文件只留 image
- 构建即推送：docker compose build 后 docker compose push 推到私有仓库
- CI 里构建并推镜像，部署机只做拉取，不必保留 Dockerfile
- 多阶段构建选择目标阶段：用 build.target 只产出运行阶段
- 排查“改了代码容器却没变”：确认该服务到底走构建还是拉取
- 本地复现线上镜像：用同样的 tag 与构建参数重建，减少环境差异
示例
示例
services:
api:
build:
context: ./api
dockerfile: Dockerfile
target: runtime # 多阶段里只构建到运行阶段
args:
APP_VERSION: "1.4.2" # 构建参数，切勿放凭据
image: registry.example.com/team/app/api:1.4.2 # 构建结果的命名与推送目标两种写法组合后的行为
| 写法 | 实际行为 | 适用场景 |
|---|---|---|
| 只写 image | 直接拉取镜像 | 生产部署，镜像来自仓库 |
| 只写 build | 构建并生成镜像 | 本地开发 |
| 两者都写 | 先构建，结果按 image 命名 | 构建与推送一体，CI 常见 |
| build 带 target | 只构建到指定阶段 | 调试或分阶段产出 |
| build 带 cache_from | 构建时复用外部缓存 | CI 提速 |
只写 image 时 Compose 不会构建：本地改了 Dockerfile 却不生效，通常就是少了 build 字段，或者根本走了另一份覆盖文件。
build.context 决定哪些文件能被 COPY 使用，路径写错会构建出与预期不一致的镜像，构建日志里的上下文文件列表能提前暴露问题。
构建参数只影响构建过程，运行期配置要用 environment 或挂载文件，两类参数分开管，排查时不容易混淆。