Docker Compose健康检查的核心是确保服务真正就绪而非仅进程运行，需配合depends_on的service_healthy条件、合理设置start_period/timeout/retries参数，并为不同服务选用可靠检测命令（如pg_isready或curl健康接口）。
依赖服务启动超时不是“服务没起来”，而是健康检查在应用真正就绪前就失败了。关键不在等更久，而在让检查更准、时机更对。
确认健康检查是否真在起作用
很多人以为 depends_on 就能保证服务可用，其实它只等容器运行，不等应用就绪。必须配合 healthcheck 才算真正依赖。先检查你的服务有没有定义 healthcheck，再确认被依赖的服务（比如数据库）是否设置了合理的 start_period 和 timeout —— 如果没设，Docker 默认 start_period 是 0s，意味着一启动就立刻检查，而 PostgreSQL 初始化常需 10–20 秒，必然超时。
- 用 docker-compose ps 查看容器状态，若显示 starting 或 unhealthy，说明健康检查已介入但失败
- 用 docker-compose logs <service> 查看目标服务日志，确认它实际何时输出 “ready” 或监听端口（如 Postgres 的 “database system is ready to accept connections”）
- 确保 healthcheck 中的 test 命令能在容器内执行成功（例如 curl localhost:5432 不行，得用 pg_isready -h localhost -U postgres）
调参要匹配真实启动耗时
别套模板值。start_period 应略大于你观察到的实际就绪时间，timeout 要大于单次检查命令的典型响应时间，而不是越长越好——过长会拖慢整体启动节奏。
- start_period：设为实测启动时间 + 5–10 秒缓冲（如 DB 实际 18 秒就绪，设 25s）
- timeout：curl 或 pg_isready 这类命令一般 2–3 秒足够，设 5s 即可；避免设成 30s，否则一次失败就要等半分钟
- retries：设 3–5 次较稳妥，既容错又不放任失败
检查命令本身是否可靠
用 curl 检查数据库？这本质是 HTTP 健康探针，但 PostgreSQL 没 HTTP 接口。错误命令不仅无效，还可能因报错退出导致健康检查直接失败。
- 数据库推荐用 pg_isready（PostgreSQL）、mysqladmin ping（MySQL）或 redis-cli ping
- Web 服务用 curl 时，确保路径正确、端口暴露、且服务已绑定到 0.0.0.0（而非 127.0.0.1）
- 避免在 test 中写复杂逻辑；优先用轻量、原子性高的命令，减少超时风险
验证依赖链是否闭环
即使 A 依赖 B，B 依赖 C，也不能只给 B 加 healthcheck。C 若没健康检查，A 启动时 B 可能“运行中”但仍在等 C，结果 A 还是连不上。
- 每个被依赖的服务都应独立定义 healthcheck，并设置合理参数
- 在 depends_on 中显式声明 condition: service_healthy，强制上游等待下游真正健康
- 示例：depends_on:
db:
condition: service_healthy
