depends_on在有状态服务重启时导致启动阻塞，本质是依赖判断机制失效与缺乏就绪反馈闭环；应通过healthcheck定义真实就绪标准、上游支持自动重连、合理设置condition及预留降级缓冲来构建弹性依赖模型。
depends_on 在有状态服务（如数据库、Redis）重启时出现“独占锁死”，本质不是锁的问题，而是依赖判断机制失效 + 缺乏就绪反馈闭环导致的启动阻塞或无限等待。它不会真加锁，但会让下游服务卡在“等健康”却等不到响应的状态，表现为容器反复重启、日志静默、端口不监听。
下面从四个关键角度给出可落地的解决路径：
用 healthcheck 定义真实就绪标准
depends_on 默认只认容器 running 状态，而有状态服务重启后常需数秒到数十秒完成初始化（比如 PostgreSQL 加载 WAL、MySQL 执行 init.sql）。必须用 healthcheck 告诉 Docker：“这个容器只有能真正响应请求才算健康”。
db:
image: postgres:15
environment:
POSTGRES_DB: myapp
POSTGRES_PASSWORD: secret
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres -d myapp"]
interval: 5s
timeout: 5s
retries: 12 # 允许最长 60 秒等待（5s×12）
start_period: 30s # 启动后宽限期，避免初始检测误判start_period 很关键——它让健康检查在容器启动后延迟开始，避开服务冷启动的“假死期”。
让上游服务支持重启后自动重连，而非只靠启动时等待
即使 web 服务等到了 db 健康才启动，若 db 中途重启，web 不会自动感知、也不会重连，常因连接池持有失效连接而持续报错（如 connection reset by peer）。
应在应用代码中实现：
- 连接池配置启用
testOnBorrow或validationQuery - 数据库客户端使用带指数退避的重试逻辑（如
retry: 5, backoff: 2^N * 100ms） - 捕获
SQLSTATE 08006（PostgreSQL 连接中断）、HY000（MySQL）等错误码并触发重连
这不是 Docker 的事，但它是打破“重启即雪崩”的必要一环。
避免 condition: service_healthy 成为单点故障
如果 db 健康检查本身写得不合理（比如用 nc -z db 5432 只测端口通），可能端口开了但服务未就绪，导致 web 误判启动；反之，若检查太严（如强制查某张表是否存在），又可能永远不健康。
推荐组合策略：
- 主健康检查用
pg_isready/mysqladmin ping—— 验证服务进程可用 - 辅助就绪检查放在应用启动脚本里（如
wait-for-db.sh），执行一条轻量 SQL（SELECT 1）确认 DB 已接受查询
给重启留出缓冲与降级空间
有状态服务重启时，别让整个链路停摆。可在 docker-compose.yml 中加入：
-
restart: unless-stopped：保证服务异常退出后自动拉起 -
deploy.restart_policy.condition: on-failure：配合健康检查更精准控制 - 对非核心依赖（如日志收集器、指标上报），改用
depends_on: [svc]（无 condition），允许其延迟就绪
同时，在应用层预留“降级开关”：当 DB 不可用超 30 秒，自动切换至缓存读取或返回友好提示，而非直接崩溃。
这些做法合起来，就把原来僵硬的“启动等一次”变成了“运行中持续感知 + 主动恢复”的弹性依赖模型。
