“依赖风暴”的本质是服务增多导致启动顺序失控、健康状态不可知、网络发现不稳定及循环/隐式依赖激增引发的级联失败；解决需分层控制：稳启动顺序、验服务就绪、隔离通信路径，并辅以健康检查、服务自治、统一网络与静态校验。
大规模编排中所谓“依赖风暴”，本质是服务数量增多后，启动顺序不可控、健康状态不感知、网络发现不稳定、循环/隐式依赖激增共同导致的级联失败。它不是单个配置问题，而是系统性协调缺失。解决关键不在堆功能，而在分层控制：先稳启动顺序，再验服务就绪，最后隔离通信路径。
用 healthcheck + service_healthy 替代裸 depends_on
这是最直接、最有效的第一道防线。默认 depends_on: db 只等容器 Running 状态，而 PostgreSQL 容器 Running 后可能还需 5–10 秒才完成初始化、接受连接。此时上游服务一连就崩。
- 为每个关键中间件（数据库、缓存、消息队列）显式定义
healthcheck，使用语义化检测命令（如pg_isready、redis-cli ping、curl -f http://localhost:8080/actuator/health） - 在依赖方声明中改用对象语法：
depends_on: { db: { condition: service_healthy } } - 务必设置
start_period（尤其对慢启动服务），避免健康检查在初始化完成前过早失败
拆解长依赖链，引入启动探针与重试兜底
当 A → B → C → D 形成四层依赖，任意一环延迟都会放大下游等待时间，且 Compose 不支持跨服务健康状态传递。这时需放弃“全靠 Compose 等待”的幻想，转为服务自治。
- 在应用容器内集成轻量探针工具（如
wait-for-it.sh或dockerize），让服务启动命令变成：wait-for-it db:5432 --timeout=60 -- python app.py - 应用代码自身也应具备连接重试机制（指数退避），而非依赖外部编排保证“一次就通”
- 对非核心依赖（如日志 agent、指标 exporter），改用软依赖：启动时不阻塞，运行时异步上报失败并降级
收敛网络模型，禁用 host 模式与 links，统一用自定义 bridge
混合网络模式（比如部分服务用 network_mode: host，部分用默认 bridge）会破坏 Docker 内置 DNS 解析，导致服务名无法解析——这是大规模场景下最隐蔽的“连接超时”根源。
- 整个项目只使用一个自定义 bridge 网络（如
app-network），所有服务显式加入：networks: [app-network] - 彻底弃用
links（已废弃）和network_mode: host（破坏服务发现） - 若需主机端口暴露，仅在边缘服务（如 API Gateway、Nginx）上做
ports映射；内部服务间通信一律用service-name:port，不走宿主机 IP
可视化依赖图 + 静态校验，提前拦截循环与冗余依赖
50+ 服务时，靠人工维护 depends_on 极易引入循环（A→B→A）或无意义强依赖（前端硬依赖后台任务调度器）。必须引入自动化守门人。
- 用
docker compose config --services和第三方工具（如dc-graph）生成依赖拓扑图，一眼识别环路与孤岛 - 在 CI 流程中加入 YAML 静态检查：禁止
depends_on出现在无实际调用关系的服务间；对condition: service_healthy缺失的强依赖发出警告 - 将“是否需要启动依赖”下沉到服务契约层面：每个服务在 README 或 OpenAPI 中明确标注其运行时依赖项，而非仅靠 compose 文件隐含表达
