Docker重启策略由守护进程原生实现，不依赖外部守护进程；它在容器启动时持久化策略至hostconfig.json，宿主机重启或容器退出后自动按配置拉起容器。
docker 重启策略本身不依赖外部守护进程，而是由 docker 守护进程（dockerd）原生实现并强制执行的。只要守护进程在运行，它就会持续监控容器状态，并按配置的 --restart 策略自动响应退出事件——无需额外守护进程介入。
重启策略如何被守护进程接管
Docker 守护进程在容器启动时读取并持久化重启策略（如 always 或 unless-stopped），将其写入容器的配置文件（位于 /var/lib/docker/containers/<id>/hostconfig.json）。此后，无论容器因崩溃、OOM killer 终止，还是宿主机重启后守护进程恢复，dockerd 都会主动检查该配置，并立即拉起容器。
- 宿主机重启后，
systemctl start docker启动守护进程 → 它扫描所有含always/unless-stopped的容器 → 自动执行docker start - 容器内主进程崩溃退出（即使退出码为 0）→ 守护进程检测到状态变为
exited→ 按策略决定是否重启 - 守护进程自身异常退出再恢复，也会重载全部容器配置，维持策略一致性
真正需要守护进程的场景是健康检查协同
仅靠重启策略只能“盲目重启”，无法判断应用是否真正在提供服务。这时需结合健康检查（HEALTHCHECK）和编排层能力：
-
HEALTHCHECK命令由守护进程周期性调用，失败后标记容器为unhealthy，但不会自动重启 - 若使用
restart: on-failure，而健康检查失败又未导致主进程退出，则不会触发重启 - 因此，生产中常搭配：健康检查 +
unless-stopped+ 外部工具（如docker events监听 + 脚本docker restart）或升级到 Swarm/K8s
避免误以为需要额外守护进程
有些用户尝试用 supervisord 或 systemd 封装容器来“保活”，这是冗余且危险的：
- 会导致双重生命周期管理冲突，例如
systemd重启容器，而dockerd也同时尝试启动 - 破坏 Docker 原生状态跟踪，
docker ps和健康状态可能失真 - 守护进程应只管
dockerd本身（确保它开机自启、崩溃自拉），而非干预容器内部行为
推荐组合：守护进程保障 + 策略选型 + 健康感知
高可用落地的关键不是加守护进程，而是精准配置与分层协作：
-
基础层：确保
dockerd开机自启（systemctl enable docker） -
容器层：Web/API 类服务用
restart: unless-stopped；数据库等有状态服务慎用always，优先配on-failure+ 启动前校验脚本 -
可观测层：在镜像中定义合理
HEALTHCHECK（如检查端口连通性 + 关键接口返回码），让守护进程能识别“假存活” -
编排层（进阶）：单机够用就止步于此；多节点请直接用 Swarm 的
deploy.restart_policy或迁移到 Kubernetes，它们才真正具备跨节点调度+健康驱逐能力
