问题本质是服务启动顺序未对齐，应用容器先于数据库容器启动导致连接失败；需在docker-compose.yml中用depends_on配合healthcheck（如pg_isready）声明依赖，并在应用层添加指数退避重试机制。

这个问题本质是服务启动顺序没对齐，不是数据库“坏了”，而是应用容器比数据库容器先跑起来、急着连库却连不上。

确认依赖关系是否显式声明

在 docker-compose.yml 中，仅靠服务名先后顺序不能保证启动顺序。必须用 depends_on 明确声明依赖，并配合健康检查才真正可靠：

• 基础写法（只控制启动顺序，不校验就绪）：
  depends_on:
  - db
• 推荐写法（结合健康检查，等数据库真正可响应再启动应用）：
  depends_on:
  db:
    condition: service_healthy
• 同时确保 db 服务定义了 healthcheck，例如 PostgreSQL 可用：
  healthcheck:
  test: ["CMD-SHELL", "pg_isready -U postgres"]
  interval: 30s
  timeout: 10s
  retries: 5

应用层加兜底重试机制

即使 Compose 层做了依赖控制，网络波动或数据库短暂延迟仍可能发生。建议在应用代码中避免“启动即连库失败就退出”，改为：

• 连接数据库时启用指数退避重试（如最多重试 5 次，间隔从 1s 逐步延长）
• 使用带超时的连接初始化，避免卡死在阻塞调用上
• 日志中明确区分“连接拒绝”（数据库还没起来）和“认证失败”（配置错误），便于快速归因

验证数据库是否真就绪，而非仅端口开放

很多报错显示 Connection refused 或 database does not exist，但 telnet db 5432 却能通——说明端口监听了，但数据库进程尚未完成初始化（比如 PostgreSQL 正在恢复 WAL 日志）。此时：

• 不要只检查端口，要用数据库原生命令验证服务可用性（如上面 pg_isready）
• 若用 MySQL，健康检查可用：mysql --user=root --password=$MYSQL_ROOT_PASSWORD -e "SELECT 1" > /dev/null
• 查看数据库容器日志：docker-compose logs db，确认最后几行是否出现 database system is ready to accept connections 类提示

避免挂载空数据目录导致初始化卡住

如果 db 服务挂载了宿主机目录（如 ./pgdata:/var/lib/postgresql/data），而该目录非空且结构损坏，PostgreSQL 启动会失败或卡在初始化阶段，但容器可能仍显示运行中。

• 首次部署建议清空挂载目录，或改用命名卷（volumes: [db_data:]），由 Docker 自动管理
• 检查挂载路径权限：Linux 下需确保目录属主为 PostgreSQL 用户（UID 999），否则初始化直接静默失败
• 临时调试可进容器手动执行初始化脚本：docker-compose exec db bash -c "ls -l /var/lib/postgresql/data"