推荐采用“基础配置文件 + 环境专属覆盖文件”的组合方式，配合 env_file 指令加载敏感变量，既能保证配置复用，又能实现环境隔离。

命令速用版

启动时通过 -f 参数指定多个配置文件，后加载的文件会覆盖前者的同名字段：

docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d

在服务定义中使用 env_file 加载变量文件：

services:
  web:
    image: nginx
    env_file:
      - ./common.env
      - ./prod.env
    environment:
      - DEBUG=false

为什么会这样

Docker Compose 的设计初衷是将应用编排定义与环境配置分离。单一配置文件往往难以兼顾不同环境的差异，例如开发环境需要挂载源码目录以便热更新，而生产环境则关注资源限制与安全策略。通过多文件叠加机制，基础文件定义通用服务结构，环境专属文件仅覆盖必要字段，如端口、环境变量或副本数，从而降低维护成本并减少配置冲突。

分步处理

1. 定义基础配置文件

创建 docker-compose.yml，包含所有环境共有的服务定义，不填写特定环境的变量值：

version: '3.8'
services:
  app:
    image: myapp:latest
    ports:
      - "${APP_PORT}:80"

2. 准备环境变量文件

为不同环境创建独立的 .env 文件，例如 .env.development 和 .env.production，内容仅包含键值对：

# .env.production
APP_PORT=8080
DB_HOST=db-prod.internal
LOG_LEVEL=warn

3. 创建环境覆盖文件

编写 docker-compose.prod.yml，通过 env_file 指令引用对应的变量文件，并覆盖生产特有配置：

version: '3.8'
services:
  app:
    env_file:
      - ./ .env.production
    deploy:
      replicas: 3

4. 启动服务

使用命令行组合文件启动，确保生产配置生效：

docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d

怎么验证是否生效

1. 检查渲染后的配置

在执行 up 之前，使用 config 命令查看最终合并后的配置，确认环境变量是否正确加载：

docker-compose -f docker-compose.yml -f docker-compose.prod.yml config

2. 进入容器验证

启动后进入容器内部，检查环境变量是否符合预期：

docker-compose exec app printenv | grep LOG_LEVEL
若输出 warn 则说明生产环境配置已生效。
常见坑
优先级混淆：Compose 文件中 environment 显式定义的变量优先级高于 env_file 引入的变量，若两者冲突，以前者为准。
敏感信息泄露：切勿将包含密码或密钥的 .env 文件提交至代码仓库，应将其加入 .gitignore。
路径引用错误：env_file 指定的路径是相对于 docker-compose.yml 文件所在目录的，移动文件位置可能导致加载失败。
变量未替换：若在 compose 文件中使用 ${VAR} 语法，确保该变量已在 .env 文件或宿主机环境中定义，否则可能被置空。
参考来源
微服务部署必看：Docker Compose 多 env 文件配置的 7 大最佳实践
Docker Compose 多环境管理终极指南
Docker-Compose 概述 (下)-阿里云开发者社区
多环境配置混乱？Docker Compose 多 env 文件实战全解析