depends_on仅确保容器运行状态，不等待服务就绪；需配合healthcheck（含start_period）、应用层探测及安全加固才能可靠实现依赖等待。
很多人以为 depends_on 就是“等它好了再启动我”，结果服务一跑就报连接拒绝、健康检查失败、日志里反复重试——其实它只管容器“跑起来”，不管里面的服务有没有真正准备好。
依赖启动顺序的三大典型误区
这些错误在本地可能不明显，但上线后极易引发雪崩式故障：
-
把 depends_on 当成健康等待：它只确保容器状态为
running，而 PostgreSQL 启动后还要初始化数据库、加载扩展、监听端口，这个过程可能耗时 10–30 秒；MySQL 同理，mysqladmin ping成功前无法建连。 -
忽略 start_period 配置：健康检查默认在容器启动后立刻开始，但很多数据库镜像（尤其是 Alpine 版）冷启动慢。没设
start_period，检查提前触发，直接判unhealthy，导致依赖服务永远等不到它。 -
健康检查命令在容器内不可用：Alpine 镜像默认无
bash、curl或pg_isready；写["CMD-SHELL", "curl -f http://localhost/health"]却没装 curl，命令直接报错退出，健康状态恒为unhealthy。
Agent 类扩展服务的安全隐患
监控代理、日志采集器等 sidecar 容器若配置不当，会成为攻击跳板或资源黑洞：
- privilege: true + host Docker socket 挂载：等于把宿主机 root 权限交给 Agent 容器，一旦被利用可逃逸并控制整个节点。
- network_mode: "service:app"：共享网络命名空间虽方便抓包，但 Agent 故障会导致主服务网络中断；且无法独立做网络策略或限速。
- 无资源限制 + 无日志轮转：Agent 在高负载下吃光 CPU 或内存，拖垮主服务；日志持续写入不清理，数天即可撑爆磁盘。
真正可靠的依赖等待方案
不要只靠 depends_on，组合使用才稳：
-
数据库加 healthcheck + condition：
db: image: postgres:16-alpine healthcheck: test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-postgres} -d ${POSTGRES_DB:-postgres}"] interval: 10s timeout: 5s retries: 5 start_period: 40s # 关键！给初始化留足时间 web: build: . depends_on: db: condition: service_healthy -
应用层主动等待（推荐用于复杂链路）：在应用容器启动命令中嵌入探测逻辑，例如：
command: > sh -c ' until nc -z db 5432; do echo "Waiting for DB..."; sleep 2; done; exec npm start'注意：nc要确保基础镜像已安装（如alpine需加apk add --no-cache netcat-openbsd）。 -
避免硬编码密码进 healthcheck：用环境变量引用（如
-p${MYSQL_ROOT_PASSWORD}），别写明文；敏感字段优先走 Docker secrets 或外部 Vault。
生产环境必须加固的细节
这些配置本地不报错，但上线就是定时炸弹：
-
所有服务设 restart 策略：至少
restart: on-failure，避免单点崩溃导致整套服务瘫痪。 -
禁用 root 用户运行：在 Dockerfile 中用
USER 1001，Compose 中加user: "1001:1001"，降低容器逃逸危害。 -
日志配额强制开启：
logging: driver: "json-file" options: max-size: "10m" max-file: "3" -
敏感信息绝不落盘：.env 文件必须
.gitignore，密码类变量不用environment:直写，改用secrets:或 runtime 注入。
