Docker容器断电后能否恢复取决于重启策略、持久化配置和Docker守护进程自启：需设restart: unless-stopped或always，数据挂载命名卷，且systemctl enable docker启用开机自启。
宿主机断电后，Docker 容器能否恢复，不取决于容器自身“记得”什么，而取决于三个硬性条件：重启策略是否启用、持久化是否到位、Docker 守护进程能否自启。断电属于非受控终止，所有正在运行的容器会强制退出（状态变为 exited 或直接 dead），此时恢复完全依赖系统级配置，而非应用层逻辑。
必须配置 restart: unless-stopped 或 always
断电后宿主机重启，Docker 守护进程启动时会扫描已存在容器，并依据其 restart 策略决定是否拉起：
-
unless-stopped 是生产环境推荐选择：容器在断电前若未被手动
docker stop，则宿主机重启后自动启动；若曾被管理员停用，则保持停止，符合运维意图 - always 会无视手动停止状态，只要守护进程起来就启动——适合绝对不可中断的核心服务，但可能干扰维护操作
- on-failure 和 no 在断电场景下基本失效：前者只响应非零退出码，而断电导致的退出码不可靠；后者直接放弃恢复
注意：该策略需在 docker run 时用 --restart=unless-stopped 显式指定，或在 docker-compose.yml 中为每个 service 设置 restart: unless-stopped。仅靠镜像或 Dockerfile 无法继承该行为。
数据不能丢：卷（volume）是恢复的前提
断电不会损坏已挂载的命名卷（named volume）或绑定挂载（bind mount）中的数据，但前提是容器启动时必须重新挂载它们：
- 使用
docker volume create myapp-data创建命名卷，并在运行时通过-v myapp-data:/app/data挂载 - 避免依赖容器内默认的可写层（如
/tmp或未挂载的/app/config）——断电后这些路径内容全部丢失 - 数据库类服务（如 PostgreSQL、MySQL）必须将
/var/lib/postgresql/data等关键路径挂载到外部卷，否则每次重启等于重装实例
验证方式：断电模拟后，进入恢复的容器执行 ls /app/data，确认上次写入的文件仍在。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
Docker 服务本身要随系统自启
如果宿主机重启后 dockerd 没有自动运行，那再好的 restart 策略也毫无意义：
- Linux 系统上运行
sudo systemctl enable docker，确保 Docker 服务设为开机自启 - 检查状态：
systemctl is-enabled docker应返回enabled；systemctl status docker应显示 active (running) - 某些精简版系统（如 CoreOS、Flatcar）或容器专用 OS 可能默认禁用 systemd 服务，需额外配置
补充一点：若使用 Docker Desktop（macOS/Windows），它不随系统开机自启，断电恢复后需手动打开应用——这不属于生产部署模型，应避免用于关键服务。
别指望健康检查“救急”
Healthcheck 在断电恢复中作用有限：
- 它只在容器已启动并运行一段时间后才开始探测，无法干预“启动失败”本身
- 若容器因依赖服务（如数据库）尚未就绪而启动失败，Healthcheck 不会触发重启——因为容器根本没走到“running”状态
- 真正需要的是启动等待机制（如
wait-for-it.sh）或编排工具的依赖声明（Docker Compose 的depends_on+ health condition）
所以 Healthcheck 是保障“运行中”的稳定性，不是解决“启动不了”的钥匙。
