容器依赖“死锁”实为服务级阻塞假象，根源在于depends_on仅控制启动顺序而不验证服务就绪，需结合healthcheck、资源限制与cgroup清理保障真可用。
服务编排中多容器依赖导致的“死锁”，通常不是传统意义上的线程级死锁，而是由启动顺序、健康就绪判断缺失、资源竞争或清理残留引发的**服务级阻塞假象**。解决关键不在于“打破循环等待”，而在于厘清依赖层级、区分容器启动与服务就绪、并补足可观测性与恢复机制。
明确 depends_on 的边界：它只管容器启停，不管服务是否可用
docker-compose.yml 中的 depends_on 仅控制容器进程的启动先后，不等待端口监听、数据库初始化完成或 API 响应返回。例如：
- PostgreSQL 容器已 running，但 initdb 还没结束，连接会直接拒绝；
- Redis 容器已启动，但 AOF 重写卡住，SET 命令超时失败；
- API 服务容器启动后立即尝试连 DB，因 DB 尚未 ready 而崩溃重启，形成反复拉起—失败—重启的“活锁”。
用 healthcheck + restart_policy 实现真就绪驱动依赖
必须配合 healthcheck 定义服务真正的可用状态，并让下游服务等待其健康后再行动：
- 在 DB 服务中定义：
healthcheck: test: ["CMD", "pg_isready", "-U", "postgres"]； - 在 API 服务中用
depends_on: db: condition: service_healthy； - 对频繁失败的服务加
restart: unless-stopped或on-failure，避免单点故障扩散。
规避资源级软死锁：Cgroup 残留与 CPU/内存节流
长周期运行后，Docker 可能遗留 cgroup 条目，导致容器显示 running，实则被内核节流（CPU throttled）或 OOM 标记但未退出——表现为响应极慢、日志卡顿、健康检查持续失败：
- 排查：
cat /sys/fs/cgroup/cpu/docker/*/cpu.stat | grep throttled_time，若每分钟 >5s 视为异常； - 清理：
docker-compose down --remove-orphans后手动rmdir /sys/fs/cgroup/*/docker/*<short-id>*（需 root）； - 预防：在 docker-compose.yml 中显式限制资源（
mem_limit,cpus），并启用 cgroup v2（推荐 Docker 24+ 默认开启）。
依赖拓扑要可观察、可干预，不能只靠静态配置
当服务链变长（如 web → api → auth → db → cache），纯 YAML 依赖易失控。建议：
- 用
docker-compose ps --services --filter status=running快速确认实际就绪服务； - 集成轻量监控（如 cAdvisor + Prometheus），采集各容器
health_status和cgroup usage指标； - 对核心依赖（如 DB、Redis）设置独立探针，一旦异常触发告警或自动执行
docker-compose restart db。
