容器处于运行状态，不代表数据库已经完成初始化或应用能够连接。部署脚本只控制启动顺序，可能仍然遇到第一次启动失败。应区分容器创建、进程运行与服务就绪。
为依赖定义可验证的就绪条件
检查数据库是否能够接受目标业务账号连接，而不只是端口打开。Compose 可以按配置等待健康条件，但健康检查本身必须符合实际需求。不要让轻量检查执行昂贵业务查询。
应用也要处理运行中的断连
即使启动时依赖可用，之后仍可能重启或网络抖动。应用应具备受限的恢复策略、可观察的错误和合理超时，不能完全依赖启动脚本保证未来永不失败。
初始化动作要考虑多实例
多个应用同时执行数据库迁移或种子数据写入，可能产生竞争。应明确由谁执行、何时执行以及失败后怎样继续。启动依赖检查与改变数据库结构是不同职责，不宜混在一个健康接口里。
验收冷启动与重启
分别从全新环境启动、单独重启数据库、延迟依赖就绪，观察应用是否能恢复且不会无限快速重试。把预期等待时间和故障出口写入运行说明。
常见问题：增加固定 sleep 就能解决吗？
固定等待可能暂时掩盖问题，却不能适应初始化时间变化。应优先采用明确的就绪检查和受控恢复机制。
技术参考：Docker Compose：启动顺序与健康条件。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。