健康检查为外部负载均衡器提供容器真实健康状态信号，通过标准化healthy/unhealthy状态、统一探针路径与响应要求、协同超时配置及组合依赖服务就绪检查，确保流量仅导向真正可用的实例。
健康检查本身不直接“对接”外部负载均衡器，而是为它提供可靠的状态信号。外部负载均衡器（如 Nginx、HAProxy、云厂商 SLB/ALB）需要知道后端容器是否真正可用，而 healthcheck 正是让 Docker 容器主动暴露这个状态的核心机制。
让负载均衡器识别容器真实健康状态
Docker 的 healthcheck 将容器运行时状态标准化为 healthy/unhealthy，这是外部负载均衡器做流量调度的底层依据。例如：
- Nginx Plus 或 HAProxy 可通过 Docker 插件或自定义脚本读取
docker inspect <container> --format='{{.State.Health.Status}}'</container>，动态更新后端节点权重 - 阿里云 ALB、腾讯云 CLB 等支持“容器健康检查探针”，可配置 HTTP 探针路径（如
/health），与 Compose 中test命令指向同一端点 - 若使用 Consul + Fabio 或 Traefik 这类服务发现网关，它们会监听 Docker 事件并自动同步容器健康状态，无需手动配置
关键配置要对齐：路径、协议、超时
外部负载均衡器的探针设置必须与 Compose 的 healthcheck 行为一致，否则会出现“容器显示 healthy，但 LB 已剔除”的错配：
-
路径统一：Compose 中
test: ["CMD-SHELL", "curl -f http://localhost:8080/health"]，LB 探针也应请求GET /health -
响应要求一致：后端应用的
/health接口需返回 HTTP 200，且响应体不含错误内容；非 200 或超时即视为失败 -
超时与间隔协同：LB 探针的
timeout应 ≥ Compose 的timeout，interval建议 ≥ Compose 的interval，避免 LB 比 Docker 更激进地判定故障
依赖服务就绪后才允许 LB 流量进入
仅靠单个服务的健康检查还不够——如果 Web 服务依赖数据库，而 DB 容器虽已启动但尚未完成初始化，Web 即使通过自身健康检查，实际也无法工作。这时需组合使用：
- 为数据库服务配置完整
healthcheck（如pg_isready -U user -d dbname） - 在 Web 服务的
depends_on中指定条件：db: service_healthy - 确保 Web 容器启动前，DB 已标记为
healthy，此时 LB 才可能将流量导给一个真正可用的 Web 实例
生产环境建议：用 readiness 探针替代简单端口检测
很多团队只用 curl -f http://localhost:8080 检查端口通不通，这不够。应升级为语义化就绪检查：
- 应用提供
/health/ready接口，内部检查数据库连接、缓存连通性、必要配置加载等 - Compose 中
test指向该接口：["CMD-SHELL", "curl -f http://localhost:8080/health/ready"] - 外部 LB 同样探测此路径——这样 LB 剔除的不是“进程挂了”的实例，而是“业务不可用”的实例
