docker compose restart 不提供平滑重载能力，仅停止再启动容器，必然导致中断；真正零停机需结合 update_config（如 order: start-first）、healthcheck 及 replicas≥2 等声明式配置，通过 docker compose up -d 触发滚动更新。

docker compose restart 本身不提供“平滑重载”能力，它只是停止再启动容器，过程中必然存在短暂中断。真正实现多容器联合平滑重载，需结合健康检查、更新策略和部署顺序等机制，而非单纯依赖 restart 命令。

restart 命令的定位与局限

docker compose restart 适用于配置未变、仅需刷新运行状态的场景，比如日志轮转后重载配置、临时故障恢复等。它不拉取新镜像、不重建容器、不校验健康状态，也不控制启停节奏。

• 执行逻辑：对目标容器发送 SIGTERM → 等待优雅退出（默认10秒）→ 启动新实例（复用原镜像和配置）
• 无副本管理：即使服务定义了 replicas:3，restart 也会同时重启全部实例，造成服务不可用窗口
• 无就绪等待：新容器启动即视为完成，不等待 healthcheck 通过，流量可能打到未就绪实例

真正平滑重载的替代方案

要实现多容器联合、零或低中断的重载，应放弃 restart，改用 docker compose up 配合声明式更新策略：

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

• 确保 docker-compose.yml 中启用 deploy.update_config，例如：
  update_config:
    parallelism: 1
    delay: 10s
    order: start-first
• 添加可靠的 healthcheck，让 Compose 知道容器何时真正可用：
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost/health"]
    interval: 15s
    timeout: 5s
    retries: 3
• 修改镜像标签或 build context 后，运行：
  docker compose up -d --no-deps web（指定服务）或
  docker compose up -d（全量更新，按依赖顺序滚动）

多服务协同更新的关键点

当多个服务（如 web + api + cache）需联合更新时，不能靠 restart 保证时序，而应依赖 Compose 的依赖声明与启动顺序：

• 在服务间设置 depends_on + condition: service_healthy，确保上游服务就绪后再启动下游
• 对数据库类服务，避免直接重启；应先确认迁移完成、备份就绪，再用 up -d 触发可控替换
• 若必须保留旧容器做灰度对比，可临时扩缩容：先 docker compose up -d --scale web=4，等新实例就绪后，再 docker compose up -d --scale web=2

什么情况下可以用 restart 作为补充

在已具备平滑更新能力的系统中，restart 可用于局部、非关键环节的快速触达：

• 更新完配置文件（如 nginx.conf 挂载卷）后，对反向代理服务执行 restart，触发配置热重载
• 某中间件（如 Redis）仅需 flush 或 reload 参数，且其镜像支持信号重载（如 redis-server --signal USR1）
• 开发环境快速验证环境变量变更，无需重建镜像