Docker Compose中的初始化或数据库迁移容器还没完成，应用容器却已经启动，结果连到了尚未准备好的数据结构。默认的启动顺序并不等于等待任务成功结束。
对于确实需要一次性任务先执行完的部署，可以使用depends_on的service_completed_successfully条件。依赖任务必须以成功状态退出。
三个依赖条件分别等待什么
Docker官方文档区分service_started、service_healthy和service_completed_successfully。前者只等容器启动，中者依赖健康检查，后者等待一次性依赖成功结束。迁移任务结束与数据库长期健康是两种不同条件。
在Compose配置中声明完成条件
例如应用服务使用depends_on: {migrate: {condition: service_completed_successfully}}，而migrate服务运行明确会退出的迁移命令。用docker compose config检查最终解析结果，避免缩进或多文件合并改变依赖。
让失败的迁移阻止应用启动
迁移命令应在失败时返回非零退出码，不能把错误吞掉后仍返回成功。执行docker compose up -d后查看docker compose ps -a与docker compose logs migrate。退出码0才代表条件满足，不代表数据迁移结果已经人工验收。
别把常驻数据库当成完成任务
数据库容器需要继续提供服务，不适合等它成功退出。它更适合配置healthcheck并在应用中使用service_healthy，同时保留应用自己的连接重试。迁移脚本若依赖数据库健康，可在其自身依赖里单独指定条件。
上线前验证重建与重复执行
重复运行docker compose up时检查一次性任务是否会重跑，以及迁移是否具备幂等性。先在隔离环境验证退出码、应用启动顺序和失败恢复，生产库迁移前保留备份。
云服务器上的变更建议
在VPS上复现或调整配置时，先隔离验证。萤光云与LightNode可按所需地域和资源规格选择；变更前保留可恢复的备份。
FAQ
问：只写depends_on就能等数据库表建好吗？答：不能；默认启动条件不等待迁移任务成功结束，需明确配置依赖条件。
温馨提示
温馨提示：数据库结构变更先留备份和回滚方案，不要把容器启动顺序当成迁移成功的唯一证据。
