docker compose up --scale 可直接实现服务水平扩缩容，无需修改配置或依赖额外工具；需确保服务无状态、端口不冲突、共享资源隔离，并可搭配 --force-recreate、--no-deps、--dry-run 等参数增强控制力。
直接用 docker compose up --scale 就能实现服务的水平扩缩容，不需要改配置文件，也不依赖额外工具。关键在于命令时机、服务设计和参数组合。
基础用法：启动时指定副本数
这是最常用也最稳妥的方式——在首次启动或重建服务时直接设定实例数量：
- 启动 web 服务的 3 个副本：
docker compose up -d --scale web=3 - 同时扩展多个服务：
docker compose up -d --scale api=2 --scale worker=4 - 如果服务已运行，该命令会自动停止旧容器、创建新数量的实例（相当于“滚动替换”）
动态调整：已有服务上实时变更
对正在运行的服务，可以用 docker compose up --scale 覆盖当前状态（注意不是 scale 子命令）：
- 把已运行的 web 实例从 3 个缩到 1 个：
docker compose up -d --scale web=1 - Docker 会自动停止多余的容器，保留一个；扩容同理，自动补足缺失实例
- 不加
--force-recreate时，只增减容器，不重新拉镜像或重挂卷
必须满足的前提条件
不是所有服务都能安全 scale，得提前确认这几点：
- 服务必须是无状态的：比如 Web API、静态服务、消费者任务；数据库、缓存主节点等有状态服务不能直接 scale
-
端口映射要避开冲突：如果用了固定宿主机端口（如
"8080:80"），多个实例会抢同一个端口——应改用动态端口或去掉ports，靠内部网络通信 - 共享资源需隔离：多个实例若共用同一挂载卷且同时写文件，可能引发数据竞争；建议用外部存储（如 Redis、PostgreSQL）或只读卷
- 服务名必须存在于 docker-compose.yml 中，拼写大小写都要一致
配合其他参数提升可控性
单独 scale 往往不够，搭配这几个参数更实用：
-
--force-recreate：强制重建所有相关容器，确保新配置（如环境变量、健康检查）生效 -
--no-deps：只操作目标服务，不连带启动依赖项（比如只扩 web，不碰 db） -
--dry-run：模拟执行，输出将要创建/销毁的容器列表，适合上线前验证 - 结合
docker compose ps可实时查看当前各服务的实际运行实例数
