Docker Compose 里 depends_on 不等于服务可用，很多人卡在这一步

不少人写 Docker Compose 时，看见 `depends_on` 就以为问题解决了：数据库先起，应用后起，顺序对了就万事大吉。实际上它默认只保证容器启动顺序，不保证容器里的服务已经真的可用，这也是很多项目“第一次启动必报错、重启一次又好了”的根源。

最典型的场景就是 MySQL 容器已经是 running，但数据库还在初始化；这时候应用容器已经开始连库，自然报连接失败。表面看像网络问题，实质上是应用抢跑了。只靠 `depends_on`，通常挡不住这种情况。

正确思路是把“启动”改成“健康可用”

更稳的做法是给依赖服务补 `healthcheck`，再让应用依赖 `service_healthy`，或者在启动脚本里加等待逻辑。这样应用不是看见容器进程活着就冲，而是等数据库、缓存、消息队列真的准备好之后再启动。

排错时别只看容器状态

很多新手排错只看 `docker ps`，看到容器 Up 就以为服务没问题。其实更有用的是看 `docker compose logs`、看 healthcheck 结果、看应用第一次失败时的报错时间点。只要把时间线串起来，往往很快就能发现是依赖服务没 ready，而不是业务代码有多大毛病。

所以这类问题的重点，不是让容器“按顺序启动”，而是让应用“在正确的时机启动”。这两句话看着差不多，实际稳定性差得很远。