关键在于变量替换与CI/CD阶段对齐：构建时定镜像与基础配置，部署时注入环境参数，全程避免硬编码；用${VAR:-default}设非敏感默认值，敏感信息仅通过CI平台Secrets注入，多compose文件分层覆盖，最终锁定配置与镜像。
关键在于让变量替换逻辑与 ci/cd 的执行阶段对齐：构建时确定镜像和基础配置，部署时注入环境特有参数，全程避免硬编码、不依赖本地状态。
用默认值兜底，减少 CI 脚本依赖
在 docker-compose.yml 中大量使用 ${VAR:-default} 语法，把非敏感、通用参数（如端口、日志级别、镜像标签）的 fallback 值直接写死在配置里。这样即使 CI 环境没传某个变量，服务也能正常启动，不用在每个 job 里反复判断或补缺。
-
image: myapp:${IMAGE_TAG:-latest}→ CI 可传IMAGE_TAG=1.2.0，不传就用 latest -
ports: - "${HTTP_PORT:-8080}:80"→ 本地开发默认 8080，生产由 CI 注入 443 - 避免在默认值中放密码、密钥等敏感内容，只用于行为控制类配置
CI 阶段用平台变量注入，跳过 .env 文件提交
GitHub Actions、GitLab CI 或 Jenkins 的“Secrets”机制是唯一可信的敏感信息入口。所有密码、数据库连接串、API 密钥都应通过平台环境变量传入，而不是塞进 .env 提交到仓库。
- 在 CI 脚本中直接用
-e DB_PASSWORD=$DB_PASSWORD或--env-file <(echo "DB_PASSWORD=$DB_PASSWORD") - Compose 启动命令保持简洁：
docker-compose --env-file <(cat <(echo "ENV=production") <(echo "TAG=$CI_COMMIT_TAG")) up -d - 禁止将
.env.prod或类似文件纳入版本控制；它只存在于部署机或 CI runner 的临时上下文里
多 compose 文件分层覆盖，按环境切换行为
用 -f 指定多个 compose 文件，按加载顺序实现配置叠加。通用部分写在 docker-compose.yml，环境差异收在 docker-compose.prod.yml 或 docker-compose.test.yml 里。
- 测试流水线跑：
docker-compose -f docker-compose.yml -f docker-compose.test.yml up - 生产部署跑：
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up - 覆盖规则明确：后加载的文件中同名字段（如
environment、ports）会完全替换前者的值 - 例如
docker-compose.test.yml可设LOG_LEVEL=debug、禁用健康检查、预装测试数据容器
镜像版本 + Compose 文件锁定部署态
CI 构建完成后，不仅生成带 Git SHA 或语义化版本的镜像，还要把当前生效的完整 compose 配置（含多文件合并结果）存为 artifact 或打上 git tag，确保“哪次构建对应哪套配置”可追溯。
- 用
docker-compose config > deploy-compose.yml输出解析后的最终配置，作为部署依据 - 在生产服务器上运行时，不再依赖本地
.env或 CI 变量，而是固定使用这份已验证的deploy-compose.yml - 配合
docker-compose pull拉取对应镜像，实现“配置+镜像”双锁定
