1. docker compose restart#

操作特点：

• 直接重启运行中的容器（发送SIGTERM信号停止，然后启动）
• 不会重建容器
• 不会重新拉取镜像
• 不会重新读取docker-compose.yml的配置变更
• 保持容器的数据卷、网络连接不变
• 容器ID保持不变

适用场景：

• 应用代码崩溃需要快速重启
• 配置文件已通过其他方式更新（如进入容器修改）
• 需要保持容器状态不变的情况

2. docker compose down + docker compose up#

操作特点：

• down：停止并移除容器、网络（默认保留数据卷）
• up：根据当前docker-compose.yml重新创建所有资源
• 会应用docker-compose.yml的所有最新配置
• 如果镜像有更新，会拉取新镜像（取决于pull策略）
• 生成新的容器ID
• 数据卷默认保留（除非使用-v参数）

适用场景：

• 修改了docker-compose.yml配置（如端口、环境变量等）
• 需要干净的重新部署
• Docker镜像已更新，需要重新拉取
• 网络配置需要重置

3. docker restart <container>#

操作特点：

• Docker引擎级别的单个容器重启
• 与Docker Compose管理的服务无关联性感知
• 只重启指定容器，不处理依赖关系
• 容器配置不会更新（基于创建时的配置）

适用场景：

• 仅需要重启单个容器（非Compose管理或特定容器）
• 紧急情况下的快速恢复
• 调试单个容器问题

4. 对比总结#

5. 示例演示#

1
# 修改了docker-compose.yml中的端口映射
2
# 方法1：restart不会生效（容器配置不变）
3
docker compose restart  # ❌ 端口映射不会改变
4

5
# 方法2：down+up会应用新配置
6
docker compose down
7
docker compose up -d   # ✅ 新的端口映射生效
8

9
# 方法3：直接重启nginx容器（如果知道容器名）
10
docker restart myapp-nginx-1  # ❌ 仅重启，不更新配置

6. 最佳实践建议#

1. 配置变更时：使用 docker compose down && docker compose up -d
2. 应用崩溃/快速重启：使用 docker compose restart
3. 更新镜像后：使用 docker compose pull && docker compose up -d
4. 完全清理重置：使用 docker compose down -v（会删除数据卷）
5. 单个容器问题：使用 docker restart 或 docker compose restart service_name

重要提示：生产环境中，docker compose restart 通常用于服务恢复，而配置变更应该通过完整的重新部署流程（down/up或部署脚本）来确保一致性。