关键在于确保Docker服务开机自启且容器配置unless-stopped或always策略：先执行sudo systemctl enable docker，再用docker run -d --restart unless-stopped或docker update --restart unless-stopped设置容器，二者缺一不可。
要让容器在 Docker Daemon 崩溃后自动复活，关键不是“等 Daemon 恢复再拉起容器”，而是确保：Docker Daemon 本身能随系统开机自启，且容器已配置支持守护进程重启后自动启动的策略——目前只有 unless-stopped 和 always 满足这一条件。
必须满足两个前提条件
单独配 restart 策略不够，以下两点缺一不可：
-
Docker 服务需设置为开机自启：运行
sudo systemctl enable docker，确保宿主机重启或 Daemon 崩溃恢复后，dockerd能自动拉起； -
容器必须用
unless-stopped或always策略创建：只有这两个策略会在 Docker 守护进程重启后，主动将对应容器也启动起来；on-failure和no不具备该能力。
推荐使用 unless-stopped（生产首选）
它在 Daemon 重启后自动恢复容器，同时尊重人工干预——如果你执行过 docker stop myapp，之后 Daemon 重启时它就不会再启动，避免误覆盖运维意图。
- 新建容器时指定：
docker run -d --restart unless-stopped --name myapp nginx； - 已有容器补设：
docker update --restart unless-stopped myapp（无需停止容器，立即生效）； - 验证是否生效：
docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' myapp，输出应为unless-stopped。
慎用 always，除非你明确需要“强制复活”
它的行为比 unless-stopped 更激进：哪怕你手动 docker stop 过，只要 Docker 守护进程一重启，容器就立刻被拉起。这在调试、资源竞争或 OOM 场景下容易引发问题。
- 仅建议用于极少数绝对不可中断的核心组件（如集群协调器、证书签发服务）；
- 务必搭配
HEALTHCHECK，防止健康探针失败后仍无限拉起假活进程； - 不推荐与数据库类容器（如 PostgreSQL）直接搭配，除非已确认数据持久化和启动依赖完全可靠。
别忽略基础但致命的细节
很多“配置了却不生效”的情况，其实卡在这些地方：
- 容器必须以
-d（detached）模式运行，前台启动的容器不触发 restart 策略； - 若容器因端口被占、依赖服务未就绪而启动失败，Docker 会立即重试（无延迟），可能反复失败；建议在应用层加启动等待逻辑，或用
docker-compose的depends_on+healthcheck协同控制； - Daemon 崩溃后若未配置
live-restore: true，正在运行的容器会随 Daemon 一起终止——这不是 restart 策略的问题，而是 Daemon 自身容灾配置缺失；可在/etc/docker/daemon.json中启用：{"live-restore": true}，然后重启 dockerd。
