核心是确保上游服务真正就绪而非仅容器启动：systemd需配合after=与wants=及检测脚本，docker compose须用condition: service_healthy并配真实healthcheck（如pg_isready），应用自身应内置弹性等待逻辑（如重试连接），避免仅测端口或盲目sleep。
守护进程服务依赖检查的核心，是确保上游服务真正就绪后，下游服务才开始启动或连接——不是“容器起来了”，而是“服务能用了”。单纯按脚本顺序执行或依赖启动时间，并不可靠。
明确依赖关系，先理清谁靠谁
启动前必须确认各组件之间的实际依赖链。比如：
- HDFS 服务中，namenode 必须最先启动，datanode 才能向其注册；secondarynamenode 需要 datanode 上报块信息后才能生成检查点
- MapReduce 中，jobtracker 要等 namenode 和 datanode 都就绪，tasktracker 才能成功连接并领取任务
- Web 应用依赖数据库时，不是等 MySQL 容器“running”，而是等
mysqladmin ping或pg_isready返回成功
用健康检测代替启动等待
systemd、Docker Compose、Go Daemon 等现代工具都支持基于状态的依赖判断，而非仅看进程是否启动：
- systemd 中用
After=+Wants=声明时序和弱依赖，再配合ExecStartPre=/usr/bin/sleep 2或自定义检测脚本 - Docker Compose 中，
depends_on: [db]不够，必须加condition: service_healthy，且 db 的healthcheck要真实反映服务可用性（如用pg_isready而非只测端口） - Go Daemon 可在
SetStartFunc中嵌入重试逻辑，例如循环调用http.Get("http://upstream:8080/ready")，超时失败则返回 error
应用自身要具备弹性等待能力
最健壮的方式，是把等待逻辑下沉到服务内部：
- Python 应用启动时，不直接初始化 DB 连接池，而是先尝试连接，失败则
time.sleep(2)后重试，最多 5 次 - Node.js 项目可用
wait-on http://api:3000/health作为 npm script 前置命令 - Spring Boot 启动类中，用
@PostConstruct方法调用RestTemplate探活依赖服务，异常时抛出RuntimeException触发重试或失败退出
避免常见误区
几个高频错误容易导致依赖检查失效：
- healthcheck 只检测端口开放（
nc -z），但服务可能还在加载配置或恢复数据 - systemd 单元里写了
After=network.target，却没写Wants=network.target，导致网络未就绪就启动 - forever 或 shell 脚本中用
sleep 10代替真实检测，环境一变就失效 - 在单个 Docker 镜像里塞多个服务，既违背“一个容器一个进程”原则，又让依赖控制变得不可控
