docker compose up -d 和docker compose restart 有什么区别

一、核心区别总览

在 Docker Compose 生态中，docker compose up -d 和 docker compose restart 是两个最常用的服务管理命令，但它们的底层机制和适用场景有着本质区别：

特性	docker compose up -d	docker compose restart
工作本质	重建并启动服务（完整生命周期管理）	快速重启运行中的容器（轻量级操作）
镜像更新	会检测并拉取新镜像	完全忽略镜像更新
配置变更	应用所有 compose 文件变更	不响应任何配置修改
容器重建	可能创建新容器（如果配置变更需要）	始终复用现有容器
启动耗时	较长（完整流程）	极短（仅重启进程）
数据卷处理	可能重新挂载（如果配置变更）	保持现有挂载不变
典型执行时间	1-30秒（取决于服务复杂度）	0.1-2秒

二、命令深度解析

1. docker compose up -d 的运作机制

执行流程：

1. 解析当前目录下所有 compose 文件（包括 overrides）

2. 检查镜像更新（除非使用 --no-recreate）

3. 对比当前服务状态与期望状态的差异：

   • 新建未运行的服务容器

   • 重建配置发生变更的容器

   • 保持未变更的容器运行

4. 启动所有应运行的服务

关键特性：

# 强制重建所有容器（即使配置未变）
docker compose up -d --force-recreate

# 仅启动缺失的容器（不重建已存在的）
docker compose up -d --no-recreate

# 始终重新拉取镜像
docker compose up -d --pull always

2. docker compose restart 的运作原理

执行流程：

1. 向指定容器发送 SIGTERM 信号

2. 等待默认 10 秒的停止超时

3. 发送 SIGKILL 强制终止（如果未停止）

4. 使用完全相同的配置重新启动容器

关键特性：

# 重启特定服务
docker compose restart web worker

# 修改超时时间（单位秒）
docker compose restart -t 5

# 级联重启依赖服务
docker compose restart --no-deps web

三、典型应用场景指南

应该使用 up -d 的情况

1. 首次部署服务

   # 初始部署全套服务
   docker compose -f production.yml up -d

2. 修改 compose 配置后

   # 修改 volumes 或 environment 后
   vim docker-compose.yml && docker compose up -d

3. 更新镜像版本时

   # 更新镜像后重新部署
   docker pull nginx:1.25 && docker compose up -d

4. 环境变量变更需要生效

   # 修改.env 文件后的标准操作
   docker compose --env-file .env.prod up -d

5. 服务崩溃后的恢复

   # 当容器处于 "Exited" 状态时的标准恢复方式
   docker compose up -d

应该使用 restart 的情况

1. 应用配置热重载

   # Nginx 重载配置（容器内已配置 reload 机制）
   docker compose restart nginx

2. 临时解决内存泄漏

   # 每日凌晨重启 Java 服务
   0 3 * * * docker compose restart java-app

3. 开发环境快速重置

   # 前端开发时快速重启容器
   docker compose restart frontend

4. 连接池刷新需求

   # 数据库连接池出现僵死连接时
   docker compose restart api-service

5. 证书更新后的重载

   # 证书已通过 volume 更新，需要重新加载
   docker compose restart reverse-proxy

四、高级使用模式

组合使用技巧

1. 灰度更新策略

   # 先重启部分实例验证
   docker compose restart web1
   # 验证通过后全量更新
   docker compose up -d

2. 依赖管理

   # 只重启主服务不重启依赖的DB
   docker compose up -d --no-deps app

3. 健康检查集成

   # 带健康检查的优雅重启
   docker compose restart --timeout 30 web

性能影响对比

内存处理差异：

• up -d 会完全释放容器内存（新建容器）

• restart 可能残留内存碎片（重用容器）

网络影响：

• up -d 可能导致短暂的 TCP 连接中断

• restart 保持相同的网络命名空间

存储影响：

# up -d 可能重新创建匿名卷（除非使用 --renew-anon-volumes）
docker compose up -d --renew-anon-volumes

五、最佳实践建议

1. 开发环境：

   • 频繁代码变更 → 使用 restart 快速生效

   • 依赖变更 → 必须使用 up -d

2. CI/CD 流程：

   # 在 pipeline 中永远使用 up -d
   - run: docker compose -f docker-compose.prod.yml up -d

3. 生产环境维护：

   • 配置变更 → up -d

   • 紧急修复 → restart + 后续完整 up -d

4. 监控集成：

   # 重启后验证服务状态
   docker compose restart web && docker compose ps

5. 文档规范：

   # 在项目 README 中明确说明：
   • 使用 `up -d` 的场景：xxx
   • 使用 `restart` 的场景：xxx

通过深入理解这两个命令的差异，开发者可以构建出更健壮的容器化应用管理策略，在运维效率和系统稳定性之间取得最佳平衡。