Docker Compose：环境变量与依赖顺序

配置 Compose 环境变量与变量替换

在 Docker Compose 中，环境变量的管理涉及多个层级。首先，.env 文件默认位于 compose.yaml 同级目录，用于定义宿主机层面的变量，Compose 在解析 YAML 时会读取这些值进行 ${VAR} 替换。其次，environment 指令直接在服务定义中声明容器内的环境变量，支持键值对或列表格式。env_file 则允许引用外部文件批量注入变量。变量优先级遵循明确规则：Compose 命令行参数（如 --env-file）最高，其次是 .env 文件，最后是服务内 environment 覆盖同名变量。例如，在 .env 中设置 DB_PORT=5432，Compose 解析 ports: ["${DB_PORT}:5432"] 时会替换为宿主机端口。若服务内 environment 再次定义 DB_PORT=3306，容器内部实际生效的是 3306，但端口映射仍使用 .env 的值。务必注意，Compose 变量替换发生在文件解析阶段，仅影响 YAML 结构，而 environment 注入的是容器运行时环境变量，两者作用域不同。

使用 depends_on 控制服务依赖顺序

depends_on 是 Docker Compose 中声明服务间依赖关系的核心指令，其核心作用是控制容器的启动与停止顺序，而非等待应用内部就绪。短语法采用列表形式，如 depends_on: [db, redis]，Compose 会确保 db 和 redis 容器先于当前服务启动，并在停止时按逆序关闭。长语法则提供更精细的控制，支持 condition 参数，如 depends_on: db: condition: service_started。必须明确，service_started 仅表示容器进程已创建，不代表数据库已监听端口或完成初始化。许多开发者误以为 depends_on 能解决“应用过早连接未就绪数据库”的问题，实际上它只保证容器生命周期顺序。若需真正的就绪等待，必须结合健康检查机制。在复杂微服务架构中，合理划分依赖链可避免启动死锁，但应避免过度依赖导致不必要的串行启动延迟。

用健康检查实现真正的就绪依赖

要实现服务真正可用后再启动依赖方，必须组合使用 healthcheck 与 depends_on 的 condition: service_healthy。健康检查通过定期执行指定命令探测容器状态，例如为 PostgreSQL 配置 healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"]，配合 interval: 10s、timeout: 5s 和 retries: 5。当该服务在 docker compose ps 中显示为 healthy 状态时，依赖它的 Web 服务才会开始启动。完整配置示例中，app 服务声明 depends_on: db: condition: service_healthy，Compose 引擎会轮询数据库健康状态，直到连续成功或超时。此机制有效避免了应用因数据库未初始化完成而抛出连接拒绝错误。验证时可通过 docker inspect 查看 State.Health.Status 字段，确保健康检查逻辑与实际业务探针一致，避免虚假健康状态导致依赖链失效。

启动验证与常见环境变量、依赖顺序陷阱

部署多容器应用前，务必使用 docker compose config 验证最终渲染的 YAML，该命令会展开所有变量替换并输出完整配置，是排查变量未生效的首选工具。启动后通过 docker compose ps 观察服务状态与健康标识，结合 docker compose logs -f 实时追踪容器输出。常见陷阱包括：.env 文件未与 compose.yaml 同级导致变量读取失败；误将 depends_on 当作就绪等待，引发应用启动即崩溃；健康检查命令路径错误或权限不足导致状态始终为 starting。排查时，可先执行 docker compose config 确认变量注入结果，再检查健康检查脚本是否在容器内可执行。若服务卡在 starting，通常需调整 retries 或修正探针逻辑。掌握这些验证与排错流程，能显著提升多服务编排的稳定性与可维护性。