depends_on仅控制容器启动顺序，不保证服务就绪；必须结合healthcheck与service_healthy条件、专用网络划分、应用层重试及profiles环境分离，才能构建真正可靠的健康依赖链。
关键不在“先启动谁”，而在于“等谁真正就绪”。docker compose 的 depends_on 默认只等容器运行，不等服务可用——这是 90% 复杂项目依赖失败的根源。优化核心是把“启动顺序”升级为“健康依赖链”。
用 healthcheck + condition 替代裸 depends_on
为每个关键中间件（数据库、Redis、消息队列）显式定义健康检查，并在依赖方使用 service_healthy 条件：
- PostgreSQL 示例：
healthcheck:<br> test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]<br> interval: 10s<br> timeout: 5s<br> retries: 12 - 依赖服务写法：
depends_on:<br> db:<br> condition: service_healthy
- 避免写成
depends_on: -db，那只是“容器启动即放行”，极易因初始化延迟导致连接拒绝
拆分网络与依赖职责，避免循环和隐式耦合
不要让所有服务挤在默认网络里互相探测。按职责划分专用网络：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 后端服务（API、Agent、Worker）共用
backend网络 - 数据层（DB、Redis、ES）走
data网络，仅对 backend 开放必要端口 - 网关/前端走独立
public网络，只连 backend，不直连 data 层 - 这样既限制了服务可见范围，也从架构上杜绝了跨层反向依赖（比如 Worker 直连前端）
在应用层加轻量等待逻辑，不把所有压力压给编排层
Compose 的健康检查是基础设施层保障，应用自身仍需容错：
- 启动脚本中嵌入
wait-for-it.sh db:5432 --timeout=60 --strict --，再执行主进程 - 或在代码中实现带退避的连接重试（如 Python 的
tenacity，Go 的backoff） - 重点不是“永远不失败”，而是“失败后快速恢复”，避免因单点延迟拖垮整条链
用 .env 和 profiles 分离环境与场景依赖
复杂项目常有开发/测试/CI 多种运行组合。别靠复制 compose 文件维护差异：
- 在
.env中定义开关变量：ENABLE_MOCK_CACHE=true、USE_REAL_DB=false - 用
profiles控制服务启用：cache:<br> profiles: ["default"]<br>mock-cache:<br> profiles: ["dev", "test"]
- 启动时指定：
docker-compose --profile dev up，让依赖关系随场景动态生效
