容器自动复活需选对Restart Policy、配置真实健康检查并确保Docker服务可靠：无状态服务用on-failure:5，守护进程用unless-stopped，慎用always；已有容器可通过docker update补设策略；HEALTHCHECK须验证业务状态，配合Compose的unhealthy重启策略实现闭环自愈。
容器崩溃后自动复活，关键不是“加个参数就完事”，而是选对策略、配好健康检查、确保 docker 服务本身可靠运行。
按服务类型选对 Restart Policy
策略不是越激进越好，得看容器干啥活：
-
无状态 Web 服务（如 API、前端）：用
on-failure:5。只在程序崩溃（非零退出码）时重启，最多试 5 次，避免因配置错误、依赖未就绪等问题陷入无限循环。 -
长期守护进程（如 Nginx、Redis、PostgreSQL）：用
unless-stopped。宿主机重启后自动拉起，但如果你手动执行docker stop，它就不会再启动——运维可控，生产推荐。 -
慎用
always：它连docker stop都拦不住，一停立刻重启，调试困难；OOM 被杀后也可能反复拉起，拖垮资源。
已有容器也能补设，不用删重建
容器已经跑着但没配策略？别删重跑，直接更新：
- 先停止容器：
docker stop my-app - 补上策略：
docker update --restart unless-stopped my-app - 再启动：
docker start my-app - 验证是否生效：
docker inspect my-app --format='{{.HostConfig.RestartPolicy.Name}}'，输出应为unless-stopped或对应值。
光靠进程存活不够，必须加真实健康检查
容器进程还在，不代表服务能用——可能卡死、端口通但接口返回 502 或超时。这时 on-failure 完全无效。
- 在
Dockerfile中定义业务级探针：HEALTHCHECK --interval=20s --timeout=3s --start-period=40s --retries=3 \CMD curl -f http://localhost:3000/health || exit 1 -
/health必须返回 200 + 实际业务状态（比如{"status":"ok"}），不能只是 ping 端口或查进程。 -
--start-period=40s给冷启动留时间，--retries=3避免网络抖动误判。
让健康状态真正驱动重启（尤其 Compose 场景）
Docker 自身的健康检查不会自动重启容器——它只标记 unhealthy。要实现闭环自愈，得靠编排层联动：
- 在
docker-compose.yml中明确写：restart_policy:condition: unhealthydelay: 10smax_attempts: 3 - 这样一旦健康检查连续失败，Compose 就会停掉旧容器、拉起新实例，完成一次完整恢复。
- 别忘了确保
systemctl enable docker已执行，Docker 守护进程开机自启，否则unless-stopped在宿主机重启后根本没机会生效。
