dockerfile 本身不能实现故障切换，但通过 healthcheck 指令声明健康检查（如 cmd curl -f http://localhost:8080/health || exit 1）、合理配置 --start-period、--interval 和 --retries，并配合运行时重启策略（如 --restart=on-failure）和编排系统，才能构建完整自愈能力。
单纯靠 Dockerfile 无法实现“故障切换”，它只负责构建镜像、定义初始行为；真正的故障切换依赖运行时机制（如健康检查 + 重启策略 + 编排系统）。但 Dockerfile 是整个自动化链路的起点——它必须正确暴露健康端点、预装检测工具、并声明检查逻辑。
在 Dockerfile 中声明健康检查指令
这是最核心一步。`HEALTHCHECK` 不是可选装饰，而是容器自愈能力的声明入口：
- 使用 `CMD curl -f http://localhost:8080/health || exit 1` 这类命令，确保应用提供 `/health` 端点且返回 2xx 状态码才视为健康
- 合理设置 `--start-period`（如 40s），给慢启动应用（Spring Boot、Node.js 初始化）留出缓冲时间，避免误判为 unhealthy
- `--retries=3` 和 `--interval=10s` 组合，意味着约 30 秒内连续失败才触发状态变更，兼顾灵敏性与抗抖动
- 避免用 `ps aux | grep myapp` 这类不可靠检查——进程存在 ≠ 服务可用；应检测真实业务接口
确保健康端点真实反映业务状态
健康检查的价值取决于端点设计。一个“假健康”端点会让整个机制失效：
- 端点需验证关键依赖：比如数据库连接、缓存连通性、下游 HTTP 服务可达性，而不仅是“进程活着”
- 避免返回静态 JSON `{ "status": "UP" }` —— 应动态执行轻量级探针（如 `SELECT 1` 或 `redis-cli PING`）
- 若应用无内置健康端点，可在 Dockerfile 中注入轻量脚本（如 Python + requests），通过 `CMD` 调用它
配合运行时策略形成闭环
Dockerfile 定义“怎么查”，运行时决定“查完怎么办”。两者必须协同：
- 启动容器时必须指定 `--restart=unless-stopped` 或 `--restart=on-failure:5`，否则健康状态变为 unhealthy 也不会触发重启
- 在 docker-compose.yml 中，`healthcheck` 配置可覆盖 Dockerfile 中的声明，适合不同环境差异化设置（如测试环境缩短 interval）
- 单机场景下，Docker 自身能完成重启；生产环境建议接入 Swarm 或 Kubernetes，由编排器根据 health status 自动迁移或扩缩容
验证与调试不能跳过
写完 Dockerfile 后，必须验证健康机制是否真实生效：
- 构建镜像后运行容器：`docker run -d --name test-app --health-cmd="curl -f http://localhost:8080/health || exit 1" myapp`
- 用 `docker ps` 观察 STATUS 列是否出现 `(healthy)` 或 `(unhealthy)`
- 执行 `docker inspect test-app | jq '.State.Health'` 查看完整健康日志，确认失败原因（超时？连接拒绝？HTTP 状态码非 2xx？）
- 手动停掉应用内部服务（如 kill web server 进程），观察是否在 retries 之后状态变更为 unhealthy 并触发重启
