depends_on 默认只控制容器启动顺序，不等待服务内部进程就绪，要解决连接超时需配合健康检查或在应用层增加重试机制。
先说结论：depends_on 无法保证依赖服务完全可用，必须引入健康检查或重试逻辑。
- 先确认：查看依赖服务日志，确认是启动慢还是端口未监听。
- 先处理：在 compose 文件中配置 healthcheck 并修改 depends_on 条件。
- 再验证：重启服务后观察应用日志，确认连接成功且无超时报错。
命令速用版
在 docker-compose.yml 中为依赖服务添加健康检查，并更新主服务的 depends_on 配置：
version: '3.8'
services:
db:
image: postgres:13
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5
web:
image: myapp
depends_on:
db:
condition: service_healthy为什么会这样
Docker Compose 的 depends_on 字段仅决定容器创建的先后顺序，即先启动依赖容器，再启动当前容器。但容器启动完成不代表内部应用已经监听端口或准备好接受请求。如果依赖服务初始化耗时较长，主服务在依赖服务就绪前尝试连接，就会抛出连接超时或拒绝连接的错误。
分步处理
1. 检查依赖服务日志：使用 docker compose logs 依赖服务名 确认服务启动耗时和就绪标志。
2. 配置健康检查：在依赖服务的配置块中添加 healthcheck 字段，定义判断服务就绪的命令。
3. 更新依赖条件：将主服务的 depends_on 从列表格式改为字典格式，设置 condition 为 service_healthy。
4. 应用层重试：如果无法修改编排文件，需在代码中增加连接重试逻辑，捕获异常后间隔重试。
怎么验证是否生效
执行 docker compose up -d 后，运行 docker compose ps 观察所有服务状态是否为 healthy。随后查看主服务日志，确认不再出现 Connection refused 或 Timeout 错误。
常见坑
1. 健康检查命令错误：确保检查命令在服务容器内可执行，且能真实反映业务就绪状态。
2. 检查间隔过长：interval 设置过大会导致主服务等待时间不必要的延长，影响启动速度。
3. 网络别名混淆：确保连接字符串使用的是服务名而非容器名，避免网络解析失败。
参考来源
- Docker Compose specification, "depends_on", https://docs.docker.com/compose/compose-file/compose-file-v3/#depends_on