生产环境微服务需外置配置、环境隔离与安全约束：用 environment + env_file 分离敏感配置，profiles 控制服务启停，deploy 设置资源限制与重启策略，挂载 yaml 配置文件替代复杂环境变量。
微服务在生产环境运行，不能靠开发时的默认配置硬扛。docker-compose.yml 是编排入口，但不是配置终点——它需要与外部配置管理、环境隔离、安全约束协同工作，才能真正支撑起高可用、可运维的部署。
用 environment + env_file 分离敏感与通用配置
避免在 docker-compose.yml 里明文写数据库密码、API密钥等。把通用参数（如服务端口、日志级别）放 environment 块中，把敏感或多环境差异大的变量抽到独立文件：
- 创建 .env.production（Git 忽略），内容如：
DB_HOST=prod-db.internal
REDIS_URL=redis://:s3cr3t@cache-prod:6379/0
JWT_SECRET=2a8f1e...
- 在服务定义中引用：
environment:
- APP_ENV=production
- LOG_LEVEL=warn
env_file:
- .env.production
用 profiles 和 --profile 控制服务生命周期
生产环境不需要本地调试服务（如 Swagger UI、mock 数据库、热重载代理）。用 profiles 显式标记非核心组件：
- 给调试服务加 profiles: ["dev"]，如：
swagger-ui:
profiles: ["dev"]
image: swaggerapi/swagger-ui - 部署时只启核心服务：
docker compose --profile production up -d - 这样既能共用一份 compose 文件，又避免误启非生产组件
用 deploy 设置资源限制与重启策略
生产容器必须防止单个服务吃光宿主机资源，也要保证故障自愈能力：
-
resources 限定 CPU / 内存上限与保留量：
deploy:
resources:
limits:
cpus: '0.5'
memory: 512M
reservations:
cpus: '0.2'
memory: 256M -
restart_policy 避免无限崩溃重启：
restart_policy:
condition: on-failure
delay: 10s
max_attempts: 3
window: 120s
挂载配置文件而非注入环境变量（适合复杂结构）
当配置项太多、有嵌套结构（如 YAML/JSON 格式）或需热更新时，环境变量就力不从心了。改用只读挂载：
- 准备 config/prod/app.yaml，包含数据库连接池、超时、熔断等完整配置
- 在服务中挂载：
volumes:
- ./config/prod/app.yaml:/app/config.yaml:ro - 应用启动时读取该路径，比拼接几十个 ENV 更清晰、更易校验
docker-compose.yml 在生产中本质是“部署契约”：它声明服务拓扑、依赖顺序、资源边界和启动约束。真正的配置应外置、分层、可审计。不复杂但容易忽略。
