docker容器“重启后自恢复”本质依赖docker守护进程开机自启和容器配置的restart policy；需先执行sudo systemctl enable docker确保服务自启，再用docker run或docker update设置unless-stopped等策略，并配合healthcheck防假活。
Docker 容器的“重启后自恢复”，本质是指宿主机重启或 Docker 服务重启后，容器能自动重新运行。这不是靠容器自己“醒来”，而是依赖两个关键环节：Docker 守护进程开机自启 + 容器配置了合适的 restart policy。
✅ 第一步：确保 Docker 服务本身开机自启
容器再怎么配策略，如果 Docker 还没启动，它就根本不会被管理。
-
检查是否已启用：
systemctl is-enabled docker
正常应输出
enabled。 -
如果未启用，立即开启：
sudo systemctl enable docker sudo systemctl start docker
⚠️ 小提示：
systemctl is-active docker应返回active；若不生效，用journalctl -u docker -n 50 --no-pager查日志。
✅ 第二步：为容器设置正确的 restart 策略
策略必须在创建时指定（docker run），或对已有容器用 docker update 补设。运行中无法通过 docker start 加上。
常用策略及适用场景：
unless-stopped
宿主机重启后自动拉起，且手动执行过docker stop的容器不会被强行重启，运维可控。
✅ 推荐用于 Nginx、PostgreSQL、Redis 等长期服务。always
无论退出原因（包括你主动docker stop），只要 Docker 启动，它就立刻拉起。
⚠️ 慎用：调试困难，可能掩盖 OOM 或死循环问题。on-failure[:N]
只有容器以非零退出码终止时才重启，可限制最多重试 N 次（如on-failure:3）。
✅ 推荐用于 API 服务、微服务等无状态应用，避免故障被掩盖。no
默认值，不重启。仅适合一次性任务或调试容器。
设置方式：
-
新建容器时：
docker run -d --restart unless-stopped --name myapp -p 8080:80 nginx
-
更新已有容器：
docker update --restart unless-stopped myapp
-
验证是否生效：
docker inspect myapp --format='{{.HostConfig.RestartPolicy.Name}}'输出应为
unless-stopped等对应值。
✅ 第三步：配合健康检查，防“假活”
进程还在，但 HTTP 接口卡死、502、超时？on-failure 和 unless-stopped 都无法感知——它们只看退出码。
解决办法：在镜像中加入真实业务探针：
HEALTHCHECK \ --interval=30s \ --timeout=3s \ --start-period=40s \ --retries=3 \ CMD curl -f http://localhost:3000/health || exit 1
-
--start-period=40s：给冷启动留时间，避免刚起就误判 -
--retries=3：连续失败 3 次才标为unhealthy，防网络抖动
⚠️ 注意：健康检查本身不触发重启，必须和 restart 策略协同。例如 on-failure 下，健康检查失败导致容器 exit 1，才会触发重启。
✅ 第四步：Docker Compose 中更精细控制（可选）
如果你用 docker-compose.yml，可让健康状态直接驱动重建：
services:
web:
image: my-web-app
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 20s
timeout: 5s
retries: 3
start_period: 40s
restart_policy:
condition: unhealthy
delay: 10s
max_attempts: 3
这样，一旦被标记为 unhealthy，Compose 会停掉旧容器、启动新实例，完成一次完整自愈闭环。
不复杂但容易忽略。核心就三点：
- Docker 服务得先开机自启
- 容器得配对的
--restart策略 - 关键服务还得加真实
HEALTHCHECK防卡死
