docker compose up --scale 是最直接的单机扩容方式，支持临时一键扩缩容；固定扩容需在docker-compose.yml中配置deploy.replicas，且须配resources限制资源，并用反向代理解决端口冲突。
用 docker compose up --scale 是最直接、最快捷的单机扩容方式，不用改配置、不重启其他服务，命令一跑，新容器立刻起来。
临时扩容：用 --scale 一键拉起多个实例
语法很简单：docker compose up --scale
- 比如把 web 服务扩到 4 个：
docker compose up --scale web=4 -d - 一次扩多个服务也支持：
docker compose up --scale web=3 --scale api=2 -d - 旧容器会自动停掉，只保留你指定数量的新实例；没加 --scale 的服务保持原状
- 下次只运行
docker compose up -d（不带 --scale），就会按 docker-compose.yml 里写的数量恢复
固定扩容：在 docker-compose.yml 里写死 replicas
适合生产环境，启动即生效，长期稳定：
- 在对应服务下加
deploy:块，例如：
web:
image: nginx
deploy:
replicas: 3
resources:
limits:
memory: 512M
cpus: '0.5'
- 必须搭配
docker compose up -d使用（不是 --scale） - 从 Compose v2.17+ 起，单机模式原生支持
replicas，无需 Swarm - 强烈建议同步配
resources，防止某个实例吃光内存或 CPU
扩容后必须检查的三件事
-
确认容器真起来了：运行
docker compose ps web，看是否列出 web-1、web-2、web-3 等多个实例 -
端口别硬绑宿主机：像
ports: ["80:80"]这种写法多副本会冲突，得换成反向代理（如 Nginx 或 Traefik）做流量分发 -
有状态服务慎扩：PostgreSQL、Redis 单节点这类服务不能直接设
replicas: 3，除非已实现主从、分片或外部协调
别踩这些坑
-
docker compose scale和旧版docker-compose scale已彻底移除，运行就报错，别再用 - 扩容不是万能的——如果服务本身没做无状态设计、没处理好会话共享或数据库连接池，加再多副本也没用
- 单纯靠 --scale 做“弹性”，缺乏监控和自动触发机制，只适合手动压测或临时应对，不适合真正自动伸缩场景
