选对--restart策略是容器基础自愈关键：无状态服务用on-failure:5防死循环，守护服务用unless-stopped保可控重启，慎用always避免调试困难；必须配合真实业务健康检查（如/health端点）和compose的unhealthy条件重启，才能防“假活”并实现完整自愈闭环。
直接用 --restart 参数就能让容器具备基础自愈能力，关键在于选对策略、避开常见陷阱，而不是堆砌配置。
选对 restart 策略，避免盲目设 always
Restart policy 不是越“激进”越好，要匹配服务类型：
- on-failure:5：推荐用于 Web API、微服务等无状态应用。只在程序崩溃（非零退出码）时重试，最多 5 次，防止死循环重启掩盖真实问题
-
unless-stopped：适合长期运行的守护型服务（如 Nginx、Redis），宿主机重启后自动拉起，但手动执行
docker stop后不会强行恢复，运维可控 -
always 要慎用：即使你主动
docker stop，它也会立刻重启，调试和维护困难；OOM 被杀后也可能反复拉起，导致资源雪崩
必须配合健康检查，防“假活”
仅靠进程是否存活（PID 1 是否在）无法判断服务是否真能响应请求。比如 Node.js 进程卡死、端口监听但不返回数据，on-failure 完全无效。
在 Dockerfile 中加入真实业务探针：
- 用
CMD curl -f http://localhost:3000/health || exit 1替代简单 ping 或 ps 检查 - 设置
--start-period=40s给应用冷启动留足时间，避免刚启就误判 - 连续
--retries=3失败才标为 unhealthy，避免网络抖动误触发
在 Compose 中让健康状态真正驱动恢复
Docker 的健康检查本身不重启容器，必须通过编排层联动。Docker Compose v2.2+ 支持基于健康状态的重启逻辑：
- 在
docker-compose.yml里明确写restart_policy: condition: unhealthy - 搭配
delay: 10s和max_attempts: 3，避免密集重建冲击依赖服务 - 这样容器被标记为 unhealthy 后，Compose 会停止旧实例、拉起新容器，完成一次完整自愈闭环
别忘了 Docker 守护进程自身要开机自启
再好的 restart 策略，也依赖 Docker 服务先跑起来：
- 执行
sudo systemctl enable docker，确保宿主机重启后 Docker 守护进程自动启动 - 否则
unless-stopped和always都不会生效——容器根本没机会被管理 - 可顺手检查：
systemctl is-enabled docker应返回enabled
