Docker容器级联启动关键在于服务就绪而非单纯进程启动，应结合healthcheck与depends_on condition、应用内主动等待、飞牛NAS延时脚本及数据库初始化脚本四层保障。
在 Docker 中配置容器级联启动顺序，关键不是让数据库“先启动”，而是确保应用真正能连上、用上数据库——比如 PostgreSQL 已通过 pg_isready 检查就绪，MySQL 已完成初始化并监听 3306 端口，而不是仅仅进程起来了就认为可以用了。
用 depends_on + healthcheck 控制就绪依赖
这是 docker-compose 最实用的组合方式。单独写 depends_on 没效果，必须搭配健康检查才能生效。
- 为数据库服务添加
healthcheck，例如 MySQL：
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: root
healthcheck:
test: ["CMD-SHELL", "mysqladmin ping -h localhost -u root --password=root || exit 1"]
interval: 10s
timeout: 5s
retries: 10
start_period: 60s
- 在应用服务中声明强依赖条件：
app:
image: my-app:latest
depends_on:
mysql:
condition: service_healthy
注意：start_period 要设得足够长（如 60 秒），覆盖 MySQL 初始化+数据导入耗时；retries 建议 ≥5，避免偶发网络抖动导致失败。
在应用容器内主动等待更可控
把等待逻辑放进自己的启动脚本里，比编排层更灵活，也适用于非 compose 场景（如直接 docker run 或飞牛 NAS）。
- 使用轻量脚本
wait-for-it.sh（可从 GitHub 下载或手写）：
#!/bin/sh
./wait-for-it.sh mysql:3306 --timeout=90 --strict -- \
java -jar /app.jar
- 或用原生命令循环检测（无需额外文件）：
while ! nc -z mysql 3306; do
echo "Waiting for MySQL..."; sleep 3
done
java -jar /app.jar
这种方式能输出明确日志，失败后可快速定位是网络不通、密码错，还是端口未开放。
对飞牛 NAS 这类不支持 healthcheck 的平台
飞牛 NAS 自带的 Docker 管理界面不支持 healthcheck 和 condition，只能靠外部调度实现顺序控制。
- 关闭相关容器的“开机自启”（UI 设置里取消勾选）
- 用社区脚本
fndocker.sh创建延时启动服务：
curl -s https://gitee.com/ewedl/fn-docker-delay/raw/master/fndocker.sh -o /tmp/fndocker.sh && sudo bash /tmp/fndocker.sh
- 按提示输入容器名顺序（如
mysql redis app），再设置首启延迟和间隔（例如 30 秒后启 mysql，再隔 20 秒启 app） - 脚本会生成 systemd 服务，系统重启后自动按序拉起
适合挂载未就绪、数据库初始化慢、或需人工干预后再启下游服务的场景。
补充：让数据库自己完成初始化
即使启动顺序正确，若数据库没数据或表结构缺失，应用仍会报错。可在 MySQL 容器启动时自动执行 SQL：
- 把
.sql或.sh文件复制进镜像的/docker-entrypoint-initdb.d/目录 - 文件按字母顺序执行，建议命名如
01-schema.sql、02-data.sql - 首次运行容器时自动初始化，后续启动跳过（避免重复执行）
这样，应用启动时面对的就是一个已建库、已有表、甚至预置了基础数据的环境，级联更稳。
