必须组合healthcheck与depends_on: {service: xxx, condition: service_healthy}：先为被依赖服务配置含start_period的健康检查（如pg_isready），再在上游服务中声明service_healthy条件，Compose才会等待其真正就绪后启动。
要在 Docker Compose 中真正实现“服务就绪后再启动依赖”，不能只靠启动顺序，必须用 healthcheck + depends_on condition 组合。单纯写 depends_on: [db] 只等容器运行，不等数据库连得上；加了健康检查并配对 condition，才能让上游服务等到底层服务真正可用。
给被依赖服务配 healthcheck（关键第一步）
健康检查不是可选功能，是联动前提。必须在数据库、Redis 等基础服务里显式定义，并且命令要真实验证服务能力：
-
test 命令要能反映业务可用性：比如 PostgreSQL 用
pg_isready，MySQL 用mysqladmin ping，HTTP 服务用curl -f http://localhost/health，而不是ps aux | grep这类只查进程的假检查 - start_period 必须设够：PostgreSQL 初始化可能要 20–40 秒，start_period 至少设为 40s，否则还没建完库就被判 unhealthy
- interval 和 timeout 要合理：间隔太短易误判，超时太短会漏掉慢响应；常见组合是 interval: 30s、timeout: 10s、retries: 3
在依赖服务中声明 service_healthy 条件
上游应用（如 API 服务）需明确告诉 Compose：“我只在 db 健康后才启动”：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 写法是
depends_on: { db: { condition: service_healthy } }，不是- db - 这个 condition 触发的是“等待逻辑”，docker-compose up 会阻塞 api 启动，直到 db 容器状态变成
healthy - 注意：它只管容器健康状态，不管你的应用代码是否已连上——连接池初始化、迁移脚本执行等仍需应用自己处理
别忽略应用层的容错设计
Compose 的健康等待解决的是“启动时序”问题，但无法覆盖运行期异常：
- 即使 db 显示 healthy，网络抖动、连接数满、事务锁死都可能导致首次请求失败
- 应用代码必须自带重试机制（如指数退避重连）、超时设置、熔断降级
- 推荐做法：启动时主动探测依赖（如用
wait-for-it.sh或自研 check script），比纯靠 Compose 更可控
验证和调试小技巧
配置完别只信日志，动手确认状态是否按预期流转：
- 启动后执行
docker-compose ps，看 db 状态是否从starting变成healthy - 用
docker inspect <container> --format '{{.State.Health.Status}}'查实时健康状态 - 故意把 test 命令写错（如改错端口），观察 api 是否真的卡住不启动，验证 condition 生效
