docker容器实现自愈需健康检查与restart: on-failure策略配合：健康检查标记unhealthy状态，该策略据此触发重启；健康检查命令须验证业务真实可用性，start_period避免冷启动误判，depends_on应设condition: service_healthy确保依赖真正就绪。
docker 容器要真正实现“自愈”，光有健康检查是不够的——它只负责标记状态（healthy/unhealthy），不负责重启。必须把健康检查和重启策略配对使用，才能让容器在业务异常时自动恢复。
健康检查 + 重启策略 = 自愈闭环
健康检查发现服务不可用，状态变成 unhealthy；重启策略捕获这个状态变化，触发容器重启。两者缺一不可。
restart: on-failure 是最常用也最推荐的搭配
它会在两种情况下重启容器：
- 进程退出码非 0
- 容器被健康检查标记为
unhealthy
配置示例（docker-compose.yml）：
services:
web:
image: myapp:latest
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
interval: 30s
timeout: 5s
retries: 3
start_period: 45s
restart: on-failure
注意：
-
on-failure不会因容器正常退出（如exit 0）而重启，避免误操作 - 它响应健康状态变化，比
always更精准，也比unless-stopped更可靠（后者不感知unhealthy）
健康检查命令必须真实反映业务可用性
不能只测端口通不通，得验证核心依赖是否就绪：
- Web 服务：调用
/health，该接口应检查数据库连接、缓存连通性、下游服务可达性 - MySQL：用
mysqladmin ping -h localhost -u root -p$MYSQL_ROOT_PASSWORD，而不是nc -z localhost 3306 - PostgreSQL：优先用
pg_isready -q -h localhost -U postgres - Go 微服务：建议用独立轻量
http.Server暴露/health，避免主服务中间件（鉴权、限流、CORS）干扰响应
返回内容建议带语义，比如 JSON：
{"status":"ok","db":"connected","cache":"ready"}
这样既方便人工排查，也利于监控系统解析。
start_period 是冷启动的关键保护伞
很多服务（Spring Boot、Gin、Node.js 应用）启动慢：初始化连接池、加载配置、预热缓存……可能需要 20–60 秒。
如果没有 start_period，健康检查一上来就执行，大概率失败，导致容器反复重启、陷入“启动→检查失败→重启”死循环。
正确做法：
- 设置
start_period: 45s（或更长，视实际冷启动时间而定） - 这段时间内，容器状态保持
starting，健康检查不执行，也不触发重启
depends_on 要配合 condition: service_healthy
默认 depends_on 只等上游容器状态变为 running，但此时 DB 可能还没完成初始化（比如 MySQL 正在执行 init.sql）。下游服务一连就报错退出，又触发自愈循环。
应改写为：
services:
app:
depends_on:
db:
condition: service_healthy
db:
image: mysql:8
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"]
interval: 20s
timeout: 10s
retries: 5
start_period: 60s
这样 app 会等到 db 真正健康（能响应 mysqladmin ping）后再启动，从源头避免依赖失败。
不复杂但容易忽略
