docker守护进程通过--restart策略实现容器自愈：always无条件重启，unless-stopped在手动停止后不重启，on-failure仅非零退出码时重启（可限次），配合healthcheck可提升状态感知能力。
守护进程管理崩溃容器，核心是让 Docker 自己接管重启逻辑，而不是依赖外部脚本或人工干预。关键不在“守护进程”这个词本身，而在于 Docker 守护进程（dockerd）内置的重启策略与健康检查机制。
用 --restart 策略让容器自动重启
Docker 原生支持在容器退出后按预设规则重启，这是最直接、最轻量的“自愈”方式。策略生效的前提是容器已以守护进程模式（-d）启动，且策略在启动时就指定：
- always：无论退出码是多少（包括 0），只要容器停止，就立即重启。适合长期运行的关键服务，比如 Nginx、数据库代理等
-
unless-stopped：和 always 类似，但若你手动执行
docker stop，它就不会再自动重启。这是生产环境更稳妥的选择，避免误操作后反复拉起 -
on-failure[:max]：只在非零退出码时重启，可限制最多重试次数（如
on-failure:3）。适合批处理类应用，防止因代码缺陷无限循环重启
示例命令：docker run -d --restart=unless-stopped --name api-server -p 3000:3000 my-api:1.2
搭配 HEALTHCHECK 实现状态感知重启
单纯靠退出码不够智能——有些容器进程没死，但内部服务已卡死（比如 HTTP 接口一直超时）。这时需要健康检查主动探测：
- 在 Dockerfile 中定义：
HEALTHCHECK --interval=10s --timeout=3s --retries=2 CMD curl -f http://localhost/health || exit 1 - 运行时配合
--restart=on-failure：一旦健康检查连续失败，Docker 会将容器标记为unhealthy，并触发重启 - 注意：健康检查本身不杀容器，它只是提供状态信号；真正执行重启动作的，仍是 restart 策略
确保守护进程本身可靠运行
Docker 守护进程（dockerd）必须开机自启且稳定，否则所有自动恢复都失效：
- Linux 系统下确认服务状态：
systemctl is-active docker和systemctl is-enabled docker - 若未启用开机自启，运行：
sudo systemctl enable docker - 宿主机重启后，只要 dockerd 启动了，设置了
unless-stopped或always的容器就会自动拉起
避免常见陷阱
自动恢复不是万能的，几个容易忽略的点：
- 容器被
docker stop停止后，always策略也不生效，只有unless-stopped能绕过这个限制 - OOM（内存溢出）被内核杀死时，退出码是 137，
on-failure可捕获，但频繁 OOM 说明资源配置不合理，需调优而非依赖重启 - 挂载的卷或网络配置错误会导致容器反复启动失败，此时 restart 策略只会不断重试，需结合
docker logs和docker inspect查根本原因
