核心是为每个数据库服务配置独立初始化逻辑、healthcheck健康检查及wait-for等待机制，确保各自schema创建、授权或种子数据加载完成且真正就绪后，再启动依赖服务，避免竞争与连接失败。
多服务编排中配置多个数据库初始化脚本，核心在于让每个数据库服务在真正就绪前完成自己的 schema 创建、用户授权或种子数据加载，同时避免服务间启动竞争或连接失败。关键不是“一起初始化”，而是“各自可控、按需等待、互不干扰”。
为每个数据库定义独立的初始化逻辑
不同数据库（如 PostgreSQL、MySQL、Redis）初始化方式不同，不能共用一个脚本。应为每类数据库服务单独配置初始化入口：
- PostgreSQL：通过 initdb 脚本 + 自定义 SQL 文件 实现。把
.sql或.sh放入镜像的/docker-entrypoint-initdb.d/目录（官方镜像原生支持） - MySQL：同样支持
/docker-entrypoint-initdb.d/下的.sql、.sql.gz或.sh，会按字母序执行 - Redis：无内置初始化机制，需在应用侧或通过 init 容器执行
redis-cli命令加载配置或预热数据
用 healthcheck + wait-for 脚本确保依赖就绪
仅靠 depends_on 不够——它只等容器启动，不等数据库服务真正可连。必须配合健康检查和等待逻辑：
- 为每个数据库服务配置 healthcheck，例如 PostgreSQL 使用
pg_isready - 在依赖它的应用服务（如 API 服务）中，用
command覆盖启动流程，先执行./wait-for db1 && ./wait-for db2，再启动主进程 - wait-for 脚本示例（通用版）：
#!/bin/sh<br>until nc -z $1 $2; do echo "Waiting for $1:$2"; sleep 2; done<br>echo "$1:$2 is ready!"
用 init 容器解耦复杂初始化任务
当初始化涉及跨库操作（如 PostgreSQL 写元数据、MySQL 同步业务表）、权限校验或条件判断时，推荐使用 init 容器：
- 为每个需初始化的数据库定义一个专用 init 服务，如
postgres-init、mysql-init - init 容器共享数据库卷或网络，执行完即退出；主数据库服务通过
depends_on: [postgres-init]确保顺序 - 优势：职责清晰、日志独立、失败易排查，不污染主服务镜像
统一管理初始化脚本的位置与版本
避免脚本散落在各处导致维护困难：
- 所有初始化 SQL 和 shell 脚本集中放在项目根目录下的
init-scripts/子目录 - 按数据库类型和环境分层，例如：
init-scripts/postgres/prod/01-schema.sql、init-scripts/mysql/dev/seed-data.sql - 在 docker-compose.yml 中通过
volumes挂载对应脚本到目标容器的初始化目录
