容器已启动不代表网关可服务：怎样核对依赖就绪条件

容器状态显示running，只能说明进程已经启动，不能证明数据库已经能完成网关需要的操作。本文用启动、可连接和查询就绪三个合成时刻区分依赖条件，给出独立Compose片段；当前未执行Docker，事件表是参考契约而非实测启动日志。

让健康条件对应真实需求

假依赖在零毫秒启动，五百毫秒可以建立连接，两千毫秒才可完成一条本地查询。若应用只等待进程started，在零毫秒就开始，业务ready是假；等待查询健康条件，则在两千毫秒开始，业务ready为真。打开TCP端口不是查询成功，能返回一个静态首页也不是数据库迁移已完成。

健康命令应覆盖应用最小依赖，又不能制造外部副作用。对网关来说，不宜把付费模型请求当成高频健康检查。可以将本地配置加载、连接和一条无副作用的依赖检查分开定义；具体检查内容由实际应用决定，不能因为模板里写了healthcheck就默认它足够。

启动依赖不能代替运行期恢复

附件在五千毫秒注入依赖再次不可用，参考ready随之变假。启动时等到健康，不代表以后每次失败都会自动按同样条件重排启动顺序。Docker官方启动顺序文档说明service_healthy条件的用途，运行期如何重连、降级或摘流，仍需要应用自身及部署策略配合。

本例配置中的健康命令文件是占位接口，必须由实际假服务实现，不能直接复制后期待不存在的脚本工作。它使用example.invalid形状的未拉取镜像，也不是可直接部署New API的成品。运行器实际读取YAML文本，检查depends_on、service_healthy和健康命令路径等片段存在；这不是完整YAML语义验证，无法确认命令在镜像里存在、拥有执行权限或返回值正确。

用事件证据替代“看起来启动了”

未来在独立本地环境复现时，让假依赖分别记录进程启动、端口开启、查询成功；应用记录开始尝试与首次ready，再按同一单调时间轴对齐。对照两份配置时只改依赖条件，避免把镜像启动速度变化混入结果。还应测健康命令本身失败、永不健康和恢复后的状态，不只保留一次成功截图。

本批运行器实际断言了早启动不ready、健康条件启动ready、后来依赖故障不ready三项逻辑，没有产生容器启动时间测量。它为实现方提供的是可审核的就绪定义。把running、healthy与业务ready分别写在验收报告里，才能知道等待条件保护到哪一层；即使启动顺序正确，也还需要为新请求准入和在途请求失败建立明确策略。

配套样本与复核入口

下载本篇独立合成输入和实验运行器，并下载运行器实际读取的c022.compose.yaml。上述文件放在同一目录后运行 python run_lab.py C022。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文提到数据库Redis与生产化清单；本文用依赖延迟夹具区分进程running、healthcheck与业务ready，不写升级备份恢复。