容器自动恢复需选对重启策略、配置健康检查并确保Docker守护进程可靠：无状态服务用on-failure:5，守护进程用unless-stopped，慎用always；已有容器可通过docker update补设策略；HEALTHCHECK须基于业务接口而非端口探测；Compose中需配置unhealthy触发重启；宿主机需启用docker开机自启。
容器意外崩溃后自动恢复，关键不是加个--restart就完事，而是选对策略、配好健康检查、确保 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 中定义业务级探针：
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 中明确写：
condition: unhealthy
delay: 10s
max_attempts: 3
- 这样一旦健康检查连续失败，Compose 就会停掉旧容器、拉起新实例，完成一次完整恢复。
别忘了确保 systemctl enable docker 已执行，Docker 守护进程开机自启，否则 unless-stopped 在宿主机重启后根本没机会生效。
