按环境拆分配置
把公共定义放在 compose.yaml，环境差异放在 override 文件里，是 Compose 的常规做法：默认文件会被自动叠加，也可以用 -f 显式指定多个文件，后面的优先。合并规则是标量与映射深合并、列表以追加或按 key 合并为主，因此同一个值可能来自不同文件；出问题时用 config 渲染最终配置，比在多个文件之间来回对照快得多。
基本信息
| 自动模式 | docker-compose.override.yml 会与主文件自动合并 |
|---|---|
| 显式多文件 | -f compose.yaml -f compose.prod.yaml，后者优先 |
| 合并规则 | 标量前者被覆盖，映射深合并，列表追加或按 key 合并 |
| 典型用途 | 本地开发 override、生产环境的资源与副本差异 |
| 验证方式 | 先用 config 渲染最终配置，再执行 up |
| 主要风险 | 隐式生效的 override 文件容易被遗忘，所有环境都受影响 |
典型使用场景
- 开发环境用 override 替换镜像与启动命令，接入调试端口
- 生产 override 调整资源上限、副本数与日志级别
- 多环境共用基础定义，差异集中在一处便于评审
- 临时接入第三方组件做集成测试，不污染主文件
- 把敏感配置分离到本地文件，避免提交进仓库
使用示例
使用示例
docker compose -f compose.yaml -f compose.prod.yaml config # 先看合并结果
docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose config --services # 确认最终服务列表
COMPOSE_FILE=compose.yaml:compose.prod.yaml docker compose up -d # 用环境变量指定合并规则
| 字段类型 | 合并行为 | 注意点 |
|---|---|---|
| 标量（镜像、重启策略） | 后者覆盖 | 覆盖关系要写在注释或文件名里，否则难追溯 |
| 映射（环境变量、标签） | 深合并，同 key 后者覆盖 | 想移除某个键不能靠留空，需要显式处理 |
| 列表（端口、卷） | 追加或按 key 合并 | 两层都写端口会叠加出多余映射 |
| 启动命令 | 后者覆盖 | 覆盖后原值完全失效，注意保留必要参数 |
| 资源与副本相关 | 深合并 | 容易只改了一半，配置意图不完整 |
override 文件是隐式生效的：仓库里留一个忘了删的 override，所有环境都会被它改配置；排查时只盯着主文件，很容易得出「配置没问题」的错误结论。
记忆要点是「标量覆盖、映射合并、列表追加」。按 key 合并的字段（端口、卷）在同名时会合并属性而不是替换整项，想让某项完全生效往往需要整项重写。