推荐使用docker compose up --scale而非已弃用的docker compose scale，因后者忽略资源限制、健康检查等关键配置；up --scale可覆盖docker-compose.yml中deploy.replicas值，支持一键扩缩容、自动处理依赖，并适用于无状态服务如Web/API，但数据库等有状态服务需谨慎缩容。
现在推荐用 docker compose up --scale，而不是已弃用的 docker compose scale 子命令。后者不读取配置文件里的资源限制、健康检查等关键设置，容易引发运行时问题。
用 up --scale 一键扩缩容
直接在启动或重部署时指定副本数，覆盖 docker-compose.yml 中的 deploy.replicas 值：
-
docker compose up -d --scale web=4 api=2：后台启动 4 个 web 和 2 个 api 容器 -
docker compose up -d --scale web=1：缩容 web 到 1 个实例，多余容器自动停止 - 可搭配
--force-recreate强制刷新配置（比如改了环境变量后扩容）
哪些服务适合 scale
扩缩容本质是水平复制，只适用于无状态服务：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- Web/API 服务：安全，天然支持负载分发
- 消息消费者（如 worker）：只要共享队列且幂等，可扩展
- 数据库、缓存、有状态中间件：不能直接 scale，缩容前必须确保主从同步、数据迁移或手动摘除节点
常见操作注意点
执行时需留意几个实际约束：
- 所有副本共用同一网络和 DNS 名，但端口映射需设为动态（如不绑定宿主机固定端口），否则会冲突
- 若服务用了
volumes，多个副本写同一路径可能引发数据混乱，建议只读挂载或用分布式存储 - 依赖服务（如
depends_on）会被自动处理，无需加--no-deps - 查看当前实例数：运行
docker compose ps，会显示 web_1、web_2 等命名实例
配置文件里写 scale 没用？
普通 docker compose up 不识别 deploy.replicas 字段，该字段仅在 Swarm 模式下生效。如果想让配置更清晰，可在 compose 文件中保留 deploy: 区块，但实际扩缩仍靠命令行参数驱动。
