必须配合healthcheck与condition：depends_on仅控启动顺序，不保服务就绪；PostgreSQL需pg_isready检查，应用须自实现重试逻辑，systemd需Wants+ExecStartPost确保强依赖。
依赖启动顺序不能只靠“谁先跑”，关键得确认“谁真能用”。healthcheck 是状态判断的依据，depends_on 只是容器生命周期的先后，两者必须配合使用，否则容易出现容器已启、服务未就绪的假成功。
在 Docker Compose 中配齐 healthcheck + condition
仅写 depends_on: [db] 没用——它只等 db 容器 启动完成，不等数据库进程监听端口、更不等连接池建好。必须补上健康检查和依赖条件：
- 给被依赖服务（如 PostgreSQL）定义真实有效的
healthcheck：用pg_isready -U postgres -d myapp，而不是curl -f http://localhost:5432或nc -z localhost 5432 - 在依赖服务（如 API 服务）中，把
depends_on升级为带条件的写法：condition: service_healthy -
start_period要设足：慢启动服务（如 Java 应用、带预热逻辑的 Go 服务）建议设为30s–60s，避免刚拉起就被判失败
应用自身加弹性等待，别全甩给编排工具
Docker Compose 的 condition 只控制容器启动时机，不保证你的代码一上来就能连上 DB。应用启动时应主动探测依赖是否可用：
- Python 项目：启动时用
psycopg2.connect(...)尝试建连，失败则time.sleep(2)后重试，最多 5 次；别在__init__.py里直接初始化连接池 - Node.js：在
npm start前加wait-on http://db:5432/ready或自定义脚本轮询/health - Spring Boot：用
@PostConstruct方法调用RestTemplate.getForObject("http://cache:6379/health", String.class)，异常时抛RuntimeException触发启动失败
systemd 场景下用 After=+Wants=+ExecStartPost 组合
Linux 系统服务若需强依赖（比如 nginx 必须等 backend API 就绪后再 reload），不能只靠 After=backend.service：
- 补上
Wants=backend.service，确保 backend 被真正启动（After不自动拉起目标服务） - 在 nginx unit 文件里加
ExecStartPost=/bin/sh -c 'sleep 3 && curl -f http://127.0.0.1:8080/ready || exit 1'，失败即中断启动流程 - 避免用
ExecStartPre做探活——它只运行一次，无法覆盖服务启动后卡住的情况
避开三个典型失效点
很多团队配置了 healthcheck 却仍踩坑，问题常出在细节：
- healthcheck 命令返回非零退出码但没触发失败：确认你用的是
curl -f（对 4xx/5xx 也报错），不是curl -I或裸curl - DB 容器健康检查通过了，但应用连不上：检查是否用了
localhost——容器内localhost指自己，应改用服务名（如db）或127.0.0.1（若监听了所有接口） - network.target 写了
After=却漏了Wants=：导致网络未就绪，容器就尝试解析服务名，DNS 失败直接卡死
