Docker Compose 命令速查表 - 多容器编排常用命令大全
面向需要把数据库、缓存、后端、前端等多个服务作为一个整体拉起、停止与升级的开发者。Compose 的核心价值不是命令本身，而是用一份 docker-compose.yml 锁定服务间的网络、依赖与配置，让整套环境可以重复起停。读完能独立用 up 拉起环境、用 logs 定位故障服务、用 down -v 彻底清理（并规避误删数据），以及用 --scale 做多实例扩容。
典型使用场景
用一份 YAML 编排多容器应用：一键启动/停止整套服务、管理网络与共享卷、查看聚合日志、按服务扩缩容，并排查依赖顺序、端口冲突与健康检查失败的编排问题。
启动与停止 5
docker compose up -ddocker compose up -d --builddocker compose stopdocker compose downdocker compose restart svc日志与状态 5
docker compose psdocker compose logs -f svcdocker compose logs --tail=100 svcdocker compose topdocker compose port svc 80配置与构建 5
docker compose configdocker compose builddocker compose pulldocker compose exec svc shdocker compose run --rm svc cmd网络与卷 5
docker compose up -d --scale svc=3docker network lsdocker compose down -vdocker volume lsdocker compose config --volumes常见问题 FAQ 5
Q: docker-compose up 和 docker-compose start 有什么区别？Q: 如何重新构建镜像？Q: 如何查看 Compose 项目的日志？Q: 如何只启动某个特定服务？Q: 如何删除所有容器和卷？参数矩阵
| 参数 | 作用 | 示例 |
|---|---|---|
up -d | 后台创建并启动所有服务 | docker compose up -d |
down | 停止并移除容器、网络（默认保留卷） | docker compose down |
ps | 查看各服务运行状态 | docker compose ps |
logs | 查看聚合日志 | docker compose logs -f web |
exec | 在运行中服务内执行命令 | docker compose exec web sh |
--build | 启动前重新构建镜像 | docker compose up -d --build |
scale / up --scale | 扩缩指定服务实例数 | docker compose up -d --scale web=3 |
restart | 重启服务 | docker compose restart web |
config | 校验并展开最终配置 | docker compose config |
pull | 仅拉取服务所用镜像 | docker compose pull |
易错点与避坑指南
现象up 后某个服务反复重启或一直 starting。
原因依赖服务未就绪（如 web 依赖 db 但无健康检查/depend_on 只等启动不等待就绪），或端口冲突。
处置为依赖服务加 healthcheck，用 depends_on 的 condition: service_healthy；用 docker compose logs 看具体报错。
现象容器间用服务名连不通。
原因服务不在同一自定义网络，或仍用 localhost 指向自身而非服务名。
处置Compose 默认建网络，用服务名（如 db）作主机名；应用连接串写服务名而非 127.0.0.1。
现象修改了 docker-compose.yml 但 up 没生效。
原因直接改文件未加 --build，或旧容器未重建。
处置改了构建相关配置后用 docker compose up -d --build；纯运行参数改动先 down 再 up。
现象down 后数据没了。
原因数据写在容器层而非命名卷，down 默认删除容器。
处置在 compose 中用 named volume 持久化数据；down 默认保留卷，必要时才加 -v 清理。
现象多个项目端口/网络名冲突。
原因Compose 默认项目名相同导致资源命名冲突。
处置用 -p 或 COMPOSE_PROJECT_NAME 区分项目；或在 compose 中显式命名网络/卷。
现象构建缓存导致代码改动没进镜像。
原因COPY 放在依赖安装之前，或 .dockerignore 漏配导致缓存命中。
处置把不常变的层放前面；用 --build 强制重建；检查 .dockerignore 是否排除了应包含的目录。
排障路径
1先校验配置再启动
docker compose config展开并验证 YAML，避免 up 时因配置错误整体失败。
2查看各服务状态与退出码
docker compose psState 列直接显示 Exit/Restarting，定位问题服务。
3跟踪某服务日志
docker compose logs -f web启动卡住时看该服务的实时输出。
4在运行中的服务内排查
docker compose exec web sh进容器验证网络连通、文件与进程状态。
命令示例
后台启动整套服务并在启动前重建镜像
docker compose up -d --build不加 -d 会占用终端输出所有服务的日志；加 --build 保证这次拿到的是刚构建出的镜像而不是旧缓存。
跟踪指定服务日志并只看最后 100 行
docker compose logs --tail=100 -f svc省略 svc 就是看全部服务的聚合日志；--tail 限制回溯行数，避免一进终端就被上万行刷屏。
进入运行中的服务容器排查
docker compose exec svc sh服务必须处于运行中才能 exec；一次性命令用 run --rm，跑完临时容器即被删除。
把某个服务水平扩容到 3 个实例
docker compose up -d --scale svc=3扩容的服务不能把宿主机端口写死，否则多个实例抢同一个宿主端口会起不来。
常见坑与注意事项
- docker compose down -v 会连命名卷一起删除，数据不可恢复，共享数据卷的生产环境执行前必须先备份。
- 用 --scale 扩容的服务不要在 compose 里写死宿主机端口，多实例会因端口冲突启动失败。
- 改了 compose 文件不要只 restart，restart 不重新解析配置也不重建容器，应先 config 校验再 up -d。
- 同一台机器上跑多个 compose 项目时注意网络名和卷名前缀都是按项目名生成的，重名会导致互相覆盖，必要时用 -p 显式区分项目名。
- build 默认走缓存，改了代码却发现镜像里还是旧内容时，加 --no-cache 做一次全量构建再验证。
提示
- compose 命令默认在当前目录找 docker-compose.yml，用 -f 指定其他文件，-p 指定项目名。
- down 默认不删卷，加 -v 才删；生产数据卷删除前先备份，命名卷删了数据找不回。
- --scale 扩容的服务端口不能写死宿主机端口，否则多实例端口冲突起不来。
常见问题
docker compose stop 和 docker compose down 我该用哪个？
看你想不想保留容器。stop 只停止服务但保留容器，后续可以快速恢复；down 会停止并删除容器和网络，容器就没了，下次要重新创建。需要同时清掉数据卷时 down 还要加 -v，但那意味着命名卷里的数据一并删除，生产环境执行前务必先备份。
docker compose run --rm 和 docker compose up -d 有什么不同？
up -d 是把整套服务拉起来常驻后台，容器会一直运行；run --rm 是针对某个服务跑一次性命令，跑完因为 --rm 立刻把临时容器删掉。前者适合长期驻留的服务，后者适合迁移脚本、临时查库这类活干完就走的场景。
compose 用的数据卷在 docker volume ls 里叫什么，怎么确认有哪些？
命名规则是「项目名_卷名」，所以看到 myapp_db 就知道是项目 myapp 定义的 db 卷，而不是手工创建的卷。想确认当前 compose 文件一共声明了哪些卷，用 docker compose config --volumes 把它列出来，不必翻 YAML 猜。
我怎么知道服务端口最终落在了宿主机的哪个端口上？
用 docker compose port svc 80，把服务名和容器内端口传进去，它会回显映射到宿主机的实际端口。这个值在宿主机端口写成 0 或交给系统分配时尤其有用，光看 compose 文件是猜不出最终端口的。
镜像更新和重新构建的先后顺序应该怎么排？
基础镜像过期先 docker compose pull 拉取新镜像，本地代码有改动再 docker compose build 重新构建，构建完用 docker compose up -d 让新镜像生效。想一条命令搞定就写 docker compose up -d --build，它会在启动前先构建。怀疑缓存导致改动没进镜像时，给 build 加 --no-cache 做全量构建。
由 巧匠 维护
公开更新于 2026年7月21日，内容持续校对官方文档。