必须结合healthcheck与depends_on的condition: service_healthy——前者定义被依赖服务（如postgresql用pg_isready）是否真正就绪，后者确保依赖服务仅在其健康后启动，避免仅等待容器运行状态。
在 Docker Compose 中，让容器“按条件启动”不是靠猜或等，而是用明确的健康状态作为判断依据。核心是把 depends_on 和 healthcheck 配合起来用——前者管顺序，后者管就绪。
用 healthcheck 定义服务是否真正可用
健康检查必须写在被依赖的服务里，比如数据库。它不是简单 ping 端口，而是执行能反映业务就绪的命令：
- PostgreSQL 推荐用
pg_isready -U postgres，它会检查监听状态和连接能力，比curl更精准 - MySQL 可用
mysqladmin ping -h localhost -u root -p${MYSQL_ROOT_PASSWORD} --silent，注意密码要通过环境变量传入 - HTTP 服务（如 Spring Boot）建议调用
/actuator/health或自定义/health端点，用curl -f保证非 2xx 响应直接失败
关键参数别硬套默认值：interval 控制频率，timeout 要略大于单次检查耗时，retries 设为 3–5 比较稳妥，start_period 必须覆盖应用冷启动时间（例如 Spring Boot 加载完数据库连接池常需 60–90 秒）。
用 depends_on + condition: service_healthy 实现真依赖
只写 depends_on: [db] 不够，必须加上 condition: service_healthy 才生效：
- 这个 condition 是 Compose v2.1+ 原生支持的语法，老版本不识别
- 它会让 web 服务等待 db 的 healthcheck 连续通过一次，才开始启动容器
- 配置示例：
web:
build: .
depends_on:
db:
condition: service_healthy
environment:
- DB_HOST=db
避免常见配置陷阱
很多启动失败其实源于细节疏忽：
-
test字段必须是数组格式，["CMD-SHELL", "pg_isready ..."]正确，test: "pg_isready"会报错 - 健康检查命令运行在容器内部，所以
curl http://localhost:8080可行，但curl http://db:5432在 db 自身的 healthcheck 里无效 - 如果基础镜像没装
pg_isready或curl，得在 Dockerfile 里提前安装，Alpine 镜像需加apk add postgresql-client或apk add curl - 不要在 web 服务里重复写 healthcheck 来“等自己”，它只对被依赖方有意义
需要更灵活控制？考虑轻量级等待工具
当 healthcheck + condition 不够用（比如跨网络、或需验证多个端点），可在应用启动前插入等待逻辑：
- 用官方推荐的
wait-for-it.sh脚本，放在 entrypoint 里，例如：
entrypoint: ["./wait-for-it.sh", "db:5432", "--", "java", "-jar", "app.jar"] - 或改用更现代的
dockerize工具，支持超时、重试、模板渲染等多种能力 - 这类方案要修改镜像内容，适合已有成熟构建流程的项目；纯 Compose 原生方案更适合快速验证和标准化部署
