直接在docker-compose.yml中配置healthcheck可验证应用真实就绪状态；需用CMD格式调用健康端点（如curl -f）、合理设置start_period（60–90s）、interval（15–30s）、timeout（略大于接口响应时间）、retries（通常为3），并配合depends_on: service_healthy实现真依赖。
直接在 docker-compose.yml 中配置 healthcheck，就能让容器自动报告应用是否真正就绪——不是只看进程是否启动，而是验证它能否响应请求、连上数据库、加载完配置等真实业务状态。
健康检查怎么写才有效
关键不是“能跑”，而是“能用”。推荐用应用自身暴露的健康端点（如 /health），而不是简单 ping 端口或查进程。例如：
-
HTTP 类服务：用
curl -f http://localhost:8080/health，返回 200 才算健康 -
数据库代理类服务：可用
nc -z localhost 5432或执行轻量 SQL 查询 -
避免 shell 依赖：优先用
CMD格式（如["CMD", "curl", "-f", "http://..."]），比CMD-SHELL更稳定、少出错
四个参数必须合理设置
光有命令不够，时间节奏要匹配应用实际行为：
- start_period：给冷启动留足时间（比如 Spring Boot 应用建议设为 60–90s）
- interval：太短（60s）故障发现慢；生产环境常用 15–30s
- timeout：应略大于健康接口平均响应时间（如接口通常耗时 800ms，设为 3s 更稳妥）
- retries：设为 3 较平衡——既防偶发网络抖动，又不拖长故障识别时间
怎么看健康状态是否生效
启动后别猜，用命令直接验证：
-
docker-compose ps→ 查看 HEALTH 列（显示healthy/unhealthy/starting） -
docker inspect <container_name> --format '{{.State.Health.Status}}'→ 获取精确状态 -
docker inspect <container_name> --format '{{json .State.Health.Log}}'→ 查最近几次检查的详细日志（含退出码、耗时、错误输出）
结合 depends_on 实现真依赖控制
仅靠 depends_on 等容器启动没用，要等它“健康”才行：
- 在依赖服务里写：
depends_on: db: condition: service_healthy - 确保上游服务（如数据库）真正响应了健康检查，下游（如 API 服务）才开始启动
- 避免因 DB 连接池未初始化、迁移脚本未执行完就发请求导致的启动失败
