在 Docker Compose 文件中，建议优先使用 unless-stopped 策略，它在容器异常退出时自动重启，但在你手动停止容器后不会再次启动，比 always 更适合日常运维场景。

先说结论：重启策略取决于服务类型，长期运行的 Web 服务推荐 unless-stopped 或 always，一次性任务适合 on-failure。

• 适合：需要高可用的后台服务、数据库或容易偶发崩溃的应用。
• 先准备：确认容器退出码含义，避免陷入无限重启循环。
• 验收：修改配置后执行 docker compose up -d 并观察容器状态。

命令速用版

在 docker-compose.yml 的服务层级下直接添加 restart 字段，以下是常见配置片段：

services:
  web:
    image: nginx
    restart: always
  worker:
    image: my-worker
    restart: on-failure

为什么会这样

Docker 的重启策略是由守护进程控制的，不是 Compose 独有的功能。设置 always 意味着无论容器是崩溃还是被手动停止，Docker 都会尝试重新启动它；而 on-failure 仅在容器以非零退出码结束时触发重启。对于需要维护或调试的场景，always 可能会导致你刚停止容器它又立刻启动，造成干扰。

分步处理

1. 打开项目的 docker-compose.yml 文件。
2. 找到需要配置的服务名称，在缩进层级下添加 restart: 策略名。
3. 保存文件，在终端运行 docker compose up -d 应用更改。
4. 如果提示配置无效，检查 YAML 缩进是否正确，确保 restart 与 image 同级。

怎么验证是否生效

使用 docker compose ps 查看容器状态，确保状态为 Up。若需确认具体策略，可运行 docker inspect <容器名> | grep -A 2 RestartPolicy，输出中应显示你设置的策略名称。公开资料中没有看到可靠的量化数据表明哪种策略能显著提升稳定性，这主要取决于应用本身的健壮性。

常见坑

• 无限重启循环：如果应用启动即崩溃，always 会导致容器反复重启，占用系统资源，建议配合 on-failure:5 限制重试次数。
• 手动停止失效：使用 always 时，docker compose stop 后容器可能会随 Docker 守护进程启动而再次运行，维护前需先移除策略或禁用容器。
• 依赖顺序：重启策略不保证服务启动顺序，若服务间有依赖，需配合 depends_on 或健康检查使用。

参考来源

• Docker Docs, "Services top-level element", https://docs.docker.com/compose/compose-file/05-services/#restart