Docker容器无原生启动前钩子，但可通过entrypoint脚本、官方镜像初始化目录（如/docker-entrypoint-initdb.d/）及Docker Compose pre-start钩子，在业务服务启动前完成数据库就绪验证、结构初始化与数据预载。
docker 容器本身没有原生的“启动前钩子”，但可以通过组合 entrypoint 脚本、初始化目录机制 和 docker compose 的 pre-start 钩子，在应用主进程运行前完成数据库初始化。关键不是等容器“启动”，而是确保数据库服务就绪、结构创建完毕、数据预载完成，再让业务服务真正开始连接和运行。
利用 MySQL/PostgreSQL 官方镜像的初始化目录
这是最轻量、最推荐的第一层初始化方式，适用于首次部署或清库重建场景：
- MySQL 官方镜像会自动执行
/docker-entrypoint-initdb.d/下所有.sql、.sh文件（仅当容器首次初始化数据库时，即MYSQL_ROOT_PASSWORD存在且数据卷为空） - PostgreSQL 官方镜像同样支持
/docker-entrypoint-initdb.d/，可执行 SQL 或 shell 脚本 - 操作方式：在构建镜像时，把建库语句、表结构、初始数据脚本 COPY 进该目录；或通过 volume 挂载包含脚本的本地目录
用 entrypoint.sh 实现应用容器的启动前等待与触发
业务容器不能假设数据库“已就绪”，需主动验证并延迟启动主进程：
- 编写
entrypoint.sh：先用nc -z db 5432或mysqladmin ping -h db -u root -p$DB_PASS --silent等待 DB 服务端口通且响应正常 - 再执行迁移命令（如
alembic upgrade head或flyway migrate），确保 schema 与代码匹配 - 最后用
exec "$@"启动原 CMD（如gunicorn app:app），保证主进程前台运行、信号可捕获 - Dockerfile 中设置
ENTRYPOINT ["./entrypoint.sh"]，CMD 不变
借助 Docker Compose 的 pre-start 钩子做前置检查
如果你使用的是较新版本的 Docker Compose（v2.20+ 支持 OCI hooks），可直接声明 pre-start 钩子：
- 它会在容器 每次启动前 执行指定命令，且运行在目标容器命名空间内，能访问相同网络和环境变量
- 示例配置：
services: api: build: . depends_on: - db pre-start: - command: sh -c 'echo "Running pre-start checks..." && curl -f http://db:5432/health || exit 1' user: "root" timeout: 60s - 注意：
pre-start是 Compose 层能力，不依赖容器内应用逻辑，适合集中管控初始化策略
避免常见陷阱
很多失败源于对“启动”和“就绪”的混淆：
-
depends_on只控制容器启动顺序，不判断数据库是否初始化完成——它看到db容器 Running 就放行，但此时 MySQL 可能还在解压系统表 - 不要在 entrypoint 中后台启动服务（如
service mysql start &），会导致容器因主进程退出而立即停止 - SQL 初始化脚本里记得显式
USE database_name;，否则可能报No database selected - 若用 volume 持久化数据库，首次初始化只触发一次；后续重启不会重复执行 init 脚本，因此迁移类操作必须由应用容器承担
