机房断电后容器自动恢复需三要素协同：docker服务开机自启（systemctl enable docker）、容器配置unless-stopped重启策略、关键数据挂载命名卷持久化，缺一不可。
机房断电属于典型的宿主机级故障，容器本身无法感知断电事件，但可通过分层防御机制实现灾后自动恢复：docker 服务自身需开机自启，容器需配置强重启策略，关键数据必须持久化，三者缺一不可。
确保 Docker 守护进程随系统启动
断电后服务器重启，若 Docker 服务未启用开机自启，所有容器将永远无法唤醒。
- 执行 systemctl enable docker.service，让 Docker 守护进程随系统启动
- 验证是否生效：systemctl is-enabled docker 应返回 enabled
- 若使用 systemd 管理（绝大多数 Linux 发行版），此步是容器自动恢复的前提
为容器设置 unless-stopped 或 always 重启策略
仅靠守护进程启动还不够——容器必须明确告诉 Docker：“我需要在宿主机恢复后立刻回来”。
- unless-stopped 是生产环境更推荐的选择：它会在宿主机重启后自动拉起容器，且尊重人工干预（docker stop 后不会强行重启）
- always 更激进：哪怕你手动停掉容器，只要 Docker 守护进程重启，它就立刻复活（适合绝对不允许中断的核心网关）
- 已运行的容器可用 docker update --restart=unless-stopped 容器名 动态补设
必须挂载持久化存储，否则“恢复”等于白恢复
断电后容器能起来，但如果应用状态、数据库文件、上传文件全存在容器临时文件系统里，重启等于重装——数据彻底丢失。
- 用 docker volume create myapp-data 创建命名卷，再通过 -v myapp-data:/app/data 挂载到容器内关键路径
- 避免直接用 -v /host/path:/container/path 绑定宿主目录（权限、路径依赖、迁移性差）
- 对数据库类容器（如 MySQL、PostgreSQL），务必把 /var/lib/mysql 或 /var/lib/postgresql/data 显式挂载到卷
补充建议：加入健康检查与依赖等待
单纯重启不等于服务可用。例如数据库容器先起来了，但应用容器抢在 DB 就绪前启动，会因连接失败反复崩溃。
- 在 docker-compose.yml 中为应用服务添加 healthcheck，并用 --init 参数启动（内置轻量 init 进程），避免僵尸进程阻塞信号，提升异常退出后的响应可靠性
- 对外暴露的服务建议配置 Liveness 探针（如 HTTP /health），让 Docker 或编排层能识别“假死”，触发真正有效的重启
