docker compose 的 build 指令专为从源码构建镜像设计，支持简写（如 build: ./src/web）和对象形式（指定 context、dockerfile、args、target），可与 image 共存但默认优先拉取；触发方式包括 docker compose build、up --build 等，配合 --no-cache、--pull 等参数实现精准控制，需确保 dockerfile 存在、.dockerignore 合理、context 最小化。
Docker Compose 的 build 指令就是专为“从源码构建镜像”设计的核心机制。你不用先写 docker build 命令，也不用手动管理路径和标签——只要在 docker-compose.yml 里声明好怎么构建，执行一条命令就能自动完成源码到镜像的转换。
build 指令怎么写才有效
build 支持两种写法，本质都是告诉 Compose：去哪找代码、用哪个 Dockerfile、传什么参数。
-
简写形式（最常用）
web: build: ./src/web
表示：以
./src/web为构建上下文，自动查找该目录下的Dockerfile。 -
对象形式（更灵活）
api: build: context: ./src/api dockerfile: Dockerfile.prod args: NODE_ENV: production target: final表示：
- 构建上下文是
./src/api - 使用
Dockerfile.prod而非默认名 - 构建时传入参数
NODE_ENV=production - 只构建多阶段 Dockerfile 中名为
final的阶段
- 构建上下文是
⚠️ 注意：
build和image可以共存，但 Compose 默认优先拉取image；若拉不到，才会 fallback 到build。想确保一定构建，就别依赖pull_policy，直接用--build启动。
怎么触发构建：关键命令组合
| 命令 | 效果 |
|---|---|
docker compose build |
仅构建镜像，不启动容器；适合 CI 或预构建 |
docker compose up --build |
先构建（仅当镜像缺失或显式要求），再启动容器；日常开发最常用 |
docker compose up --build --no-cache |
强制跳过所有缓存，完全重新构建；改了基础镜像或依赖后必用 |
docker compose build web |
只构建 web 这一个服务，节省时间 |
✅ 小技巧：改完代码后，直接
docker compose up --build，Compose 就会自动检测 Dockerfile 或上下文变化，决定是否重建某一层——不用你手动判断。
构建过程中的实用控制项
构建不是“一键黑盒”，你可以精细干预：
-
--pull：强制拉取最新基础镜像（比如python:3.11-slim更新了安全补丁） -
--build-arg KEY=VALUE：传构建参数，常用于区分 dev/prod 构建逻辑 -
--progress=plain：在 CI 环境中看每层耗时，方便优化 Dockerfile -
--parallel：多个服务同时构建，加速整体流程（默认已启用，但可显式强调）
例如：
docker compose build --build-arg ENV=staging --pull --no-cache
构建前必须检查的三件事
- ✅
Dockerfile是否真在指定路径下？build: ./app就要求./app/Dockerfile存在 - ✅
.dockerignore是否合理？漏掉node_modules或__pycache__会让上下文变大、缓存失效频繁 - ✅
context路径是否最小化？避免把整个项目根目录设为 context，否则大量无关文件上传拖慢构建
比如推荐这样组织：
project/
├── docker-compose.yml
├── .dockerignore
├── web/
│ ├── Dockerfile
│ ├── src/
│ └── package.json
└── api/
├── Dockerfile
└── main.py
那么 web 服务的 context: ./web 就很干净，不会误带 api/ 下的文件。
构建本身不复杂，但容易忽略上下文控制和缓存策略。把 build 配对好路径、Dockerfile 和参数，再用对 --build 和 --no-cache，源码到镜像的过程就能真正自动化、可复现、可调试。
