docker-compose build 仅构建镜像不启动容器，按 docker-compose.yml 中 build 指令逐个生成镜像层，适用于 CI/CD 预构建、本地验证 Dockerfile 等场景；它不创建容器、不受 restart 或 depends_on 影响，是真正“只构建”的唯一可靠方式。
直接构建但不启动 Compose 项目，靠 docker-compose build 就够了——它只拉镜像、编译 Dockerfile、生成镜像层，完全不碰容器生命周期。
用 docker-compose build 构建所有服务，不启动任何容器
这是最干净、最可控的方式。它会按 docker-compose.yml 中定义的 build 指令（包括 context、dockerfile、args）逐个构建镜像，但跳过创建和启动容器这一步。
常见使用场景：
- CI/CD 流水线中预构建镜像，后续再统一部署
- 本地开发时想验证 Dockerfile 是否能成功构建，又不想干扰正在运行的服务
- 为离线环境提前打包好镜像，之后再导入到无网络的机器上
执行命令：
docker-compose build
如果只想构建某一个服务（比如只构建 web）：
docker-compose build web
注意：build 不受 restart 策略或 depends_on 影响，也不检查端口占用、网络连通性——它只做构建这件事。
为什么不用 docker-compose up --no-start？
这个命令看似“只创建不启动”，但它实际做了三件事：解析配置 → 创建容器 → 停止容器。结果是容器已存在（docker ps -a 可见），只是状态为 Exited。这会带来几个麻烦：
- 下次
up时可能因卷挂载冲突、端口绑定残留报错 - 容器元数据（如网络连接、IP 分配）已写入，清理更费劲
- 如果服务依赖健康检查或初始化脚本，
--no-start后手动start仍可能失败——因为“创建”阶段没等依赖就绪
所以，真要“只构建”，别绕路，build 是唯一正解。
构建后怎么确认镜像已就绪？
构建完成不等于镜像可用。你需要手动验证镜像是否存在、标签是否正确：
- 运行
docker images，看是否有对应服务名（或image:指定的名称）和标签（默认是latest） - 如果
docker-compose.yml里写了image: myapp/web:1.2，就得确认myapp/web:1.2在列表里 - 若用
build:+tags:定义了多个 tag，得逐个核对
构建失败时，错误通常出在 Dockerfile 内部（如 RUN apt-get install 网络超时、COPY 路径不存在），而不是 Compose 层——所以优先看最后一行红字报错，别急着改 YAML。
Docker Desktop 里看不到构建进度？
桌面版 UI 默认不显示 build 日志流。你必须在终端里执行命令才能看到实时输出。UI 上的“Compose Projects”面板只响应 up / down 类操作，对 build 是静默的。
小技巧：
- 加
--progress=plain参数让输出更清晰（尤其在 CI 或远程 SSH 场景）：docker-compose build --progress=plain - 构建完后，在 Docker Desktop 的 “Images” 标签页里搜索服务名，能快速定位刚生成的镜像
真正容易被忽略的是：构建成功 ≠ 镜像能跑。有些镜像在 build 阶段一切正常，但一 run 就崩——比如 ENTRYPOINT 脚本权限不对、WORKDIR 路径不存在、或基础镜像里缺 glibc。这种问题只能靠 docker run --rm -it <image-name></image-name> 手动试一次。
