compose up 是什么
按编排文件把整套服务的容器创建并启动起来。它是日常使用编排工具的主要入口：读取文件里的服务定义，按依赖顺序创建网络、卷与容器。加后台参数后服务在后台运行；只改了配置没换镜像时，它会重建受影响的容器让改动生效。
基本信息
| 语法 | docker compose up [选项] [服务名...] |
|---|---|
| 常用选项 | -d 后台运行 --build 先构建镜像 --force-recreate 强制重建容器 --remove-orphans 清理多余容器 |
| 限定范围 | 命令末尾跟服务名时只处理指定服务及其依赖 |
| 默认行为 | 前台运行并聚合日志，终端中断会停止服务 |
| 项目隔离 | 同目录下的编排文件属于同一项目，项目名影响容器与网络的命名前缀 |
典型使用场景
- 本地一键起全栈环境：数据库、缓存、后端、前端用一条命令全部拉起
- 部署测试环境：把整套服务按编排文件部署到测试机，保证环境一致
- 验证配置改动：改完编排文件重新拉起，确认端口、变量、挂载都按预期生效
- 迭代单个服务：只重建改动过的那个服务，其余保持运行
- 清理历史残留：带上清理多余容器的选项，去掉文件里已删除服务留下的实例
常用示例
常用示例
docker compose up -d # 后台拉起全部服务
docker compose up -d --build web # 先重建镜像再起 web
docker compose up --force-recreate --remove-orphans -d # 强制重建并清理残留
docker compose up -d db # 只起数据库及其依赖
docker compose ps # 确认各服务状态改了什么要做什么
| 改动内容 | 需要的操作 | 原因 |
|---|---|---|
| 服务镜像内容 | 重新构建镜像再拉起 | 容器基于旧镜像，重建后才会用新镜像 |
| 端口映射 | 重新拉起触发容器重建 | 端口在创建容器时确定，重启不会应用新端口 |
| 挂载与卷 | 重新拉起触发容器重建 | 挂载配置同样属于创建期参数 |
| 环境变量 | 重新拉起触发容器重建 | 变量注入发生在创建阶段 |
| 仅进程内配置 | 重启进程或按应用方式重载 | 无需重建容器，重启即可生效 |
上线前后的检查
- 拉起前用校验命令检查文件语法，缩进错误与重复键在这里就能发现
- 确认端口没有被占用，冲突会在创建容器阶段直接失败
- 确认镜像已构建或已拉取，避免上线时才开始下载
- 拉起后逐个核对服务状态与健康检查结果，别只看命令返回成功
- 确认日志没有报错，启动阶段的错误往往只出现一次
多环境使用的注意点
- 不同环境用不同项目名或独立目录，避免容器与网络互相覆盖
- 环境差异放变量文件，编排文件保持共用，减少维护成本
- 生产环境慎用清理多余容器的选项，先确认项目范围里没有手工维护的实例
- 发布记录里保留本次使用的镜像版本，回滚时按版本重新拉起
- 编排文件进版本库，变更走评审流程，避免只改机器上的文件
默认前台运行会聚合所有服务的日志输出，本地调试方便，但生产与脚本场景统一加后台参数，避免终端断开导致服务一起停止。
只有拉起才会应用编排文件的改动。用启动已有容器的方式操作，配置改动不会生效，这是「改了没反应」的最常见原因。