depends_on仅控制容器启动顺序，不保证服务就绪；需结合healthcheck、condition: service_healthy或wait-for-it.sh等机制实现真正联运。
depends_on 只能控制容器进程的启动先后，不能保证服务真正就绪。它让 docker compose 按依赖拓扑排序启动服务，比如 web 会等 db 容器 运行起来 后再开始启动，但此时 postgresql 可能连监听端口都没打开，更别说接受连接了。
depends_on 的基本写法和作用范围
它只做一件事：确保被依赖的服务容器已处于 running 状态，不检查应用是否初始化完成、端口是否监听、数据库是否可连。
- 简单写法：
depends_on: [db, redis]—— 表示当前服务在 db 和 redis 容器启动后才启动 - 显式写法：
depends_on: db: condition: service_started—— 更清晰表达意图（Docker Compose v2.20+ 默认行为） - 不支持超时、重试或自定义判断逻辑，纯容器生命周期层面的顺序控制
为什么光靠 depends_on 不够用
常见失败场景就是应用启动太快，一上来就尝试连数据库，而 PostgreSQL 正在初始化——日志里满屏 Connection refused 或 database system is starting up。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- PostgreSQL 镜像从启动到可连接通常需要 5–15 秒，取决于数据量和配置
- Redis 虽快，但若挂载了持久化文件或执行 AOF 重放，也可能短暂不可用
- depends_on 不触发任何等待动作，只是“发个信号”说“那个容器起来了”
必须搭配健康检查才能真正生效
要让依赖关系落地，得让上游服务明确知道“db 不只是 running，而是 ready to serve”。这靠 healthcheck + condition: service_healthy 组合实现。
- 给 db 加健康检查：
pg_isready -U postgres是 PostgreSQL 推荐检测方式 - 设置合理参数：比如
start_period: 30s避免启动初期误判失败 - 上游服务改写 depends_on：
depends_on: db: condition: service_healthy - Docker 引擎会轮询 health status，直到 db 进入
healthy状态才启动 web
替代方案：用 wait-for-it.sh 做端口级探测
当目标服务镜像不支持 healthcheck（比如老版本 MySQL 或自定义二进制），或者你需要更细粒度控制（如等 HTTP 接口返回 200），可以挂载脚本主动探测。
- 把
wait-for-it.sh文件挂进容器：volumes: ["./wait-for-it.sh:/wait-for-it.sh"] - 修改启动命令：
command: sh -c "./wait-for-it.sh db:5432 --timeout=60 -- npm start" - 支持多级等待：
./wait-for-it.sh db:5432 -- ./wait-for-it.sh redis:6379 -- npm start - 缺点是增加启动时间、日志冗长，且属于应用层逻辑，不如 healthcheck 原生可靠
