直接在docker-compose.yml每个服务下配置restart字段即可实现自动重启，关键在于选对策略（no/always/on-failure/unless-stopped）、放对位置（与image、ports同级缩进）、配好healthcheck防重启风暴。
直接在 docker-compose.yml 的每个服务下配置 restart 字段，就能让容器按需自动重启。关键不是写对了字段，而是选对策略、放对位置、配好依赖。
restart 字段必须和 image、ports 同级缩进
它必须放在 services.<service-name> 下一级，且与 image、ports、environment 等字段保持相同缩进层级。缩进错误或位置错位（比如顶格写在 services: 下、或多缩进一级、或误塞进 deploy: 块里），Docker Compose 都会忽略该配置，容器启动后不会自动重启。
- ✅ 正确示例：
web:<br> image: nginx:latest<br> ports: ["80:80"]<br> restart: unless-stopped
（restart和ports对齐） - ❌ 常见错误：
– 顶格写restart: always在services:下方
– 缩进比image多两格
– 写在deploy:或healthcheck:里面
四种策略怎么选：看服务性质和运行意图
不同策略行为差异明显，选错容易导致维护困难或意外拉起：
- no：适合一次性任务或调试容器，比如日志清理脚本、数据迁移工具。退出后绝不重试。
-
on-failure[:N]：适合可能临时失败但不该无限重启的服务，比如定时任务、批处理 worker。加数字可限重试次数，避免死循环，例如
on-failure:3。 -
always：适合长期运行、不允许中断的 Web 或 API 服务。注意：即使你手动
docker-compose stop，下次 Docker 守护进程重启（如宿主机重启），它仍会自动起来。 -
unless-stopped：生产环境最推荐。它和
always行为基本一致，但会记住“你曾手动 stop 过”，之后 Docker 重启也不会再拉起——方便做计划内维护。
光设 restart 不够：防“重启风暴”要靠 healthcheck + condition
如果服务依赖数据库却等不及就开跑，可能反复崩溃重启，形成“重启风暴”。depends_on 只控制容器启动顺序，不保证服务就绪。
- 用
healthcheck定义应用层可用性判断逻辑，比如 PostgreSQL 可用性检查：test: ["CMD-SHELL", "pg_isready -U postgres"] - 再配合
depends_on的condition: service_healthy，确保上游服务真正健康后再启动下游服务 - 示例片段：
db:<br> image: postgres:13<br> healthcheck:<br> test: ["CMD-SHELL", "pg_isready -U postgres"]<br> interval: 30s<br> retries: 3<br>web:<br> build: .<br> depends_on:<br> db:<br> condition: service_healthy
重启行为对比帮你快速决策
理解每种策略在不同场景下的响应方式，能避免误配：
| 策略 | 正常退出（exit 0） | 异常退出（exit ≠ 0） | 宿主机重启后 |
|---|---|---|---|
| no | 不重启 | 不重启 | 不重启 |
| always | 重启 | 重启 | 重启 |
| unless-stopped | 重启 | 重启 | 重启（除非曾被手动 stop） |
| on-failure[:N] | 不重启 | 重启（≤ N 次） | 重启（若未达上限） |
