docker-compose.override.yml是最轻量、默认自动加载的覆盖方式，适用于本地开发快速迭代；它与docker-compose.yml叠加合并，仅需声明变更字段，标量值覆盖、映射键级合并、列表默认追加。
直接用 docker-compose.override.yml 是最轻量、最符合默认约定的模块化覆盖方式，不需要额外参数，适合本地开发快速迭代。
override.yml 的默认行为与适用场景
Compose 默认自动加载两个文件：docker-compose.yml（主配置）和同目录下的 docker-compose.override.yml（覆盖配置）。后者无需 -f 显式指定，启动时自动合并，且所有字段按规则覆盖或追加。
- 它不是“替代”，而是“叠加”：只写你想改或新增的部分，其余继承主文件
- 典型用途包括：本地挂载源码、开启调试端口、替换镜像为 dev 版本、添加临时日志配置
- 不建议在 override 中重复定义完整服务——比如主文件已定义
web，override 里只需写web:下要调整的字段即可
字段覆盖逻辑必须清楚
不同字段类型合并规则不同，理解这点才能避免意外行为：
-
标量字段（如
image、ports、restart）：后加载的值完全替换前值 -
映射字段（如
environment、labels）：键名相同则覆盖，不同则合并；例如主文件设ENV=prod，override 设DEBUG=1，最终两者都生效 -
列表字段（如
volumes、depends_on）：默认是追加而非替换；主文件挂载./src:/app，override 再加./logs:/app/logs，两者都会生效
如何安全地组织 override 配置
一个干净的 override 文件应聚焦“差异”，保持最小侵入性：
- 只写需要变更的服务段，其他服务不出现——不会影响主文件定义
- 环境变量尽量用
${VAR}占位符，配合.env文件注入，避免硬编码敏感信息 - 如果需多套覆盖（如 dev/debug/staging），就不用
.override.yml，改用显式-f加载多个命名文件，更可控 - 可借助
x-include或第三方工具（如compose-switch）做条件加载，但原生 Compose 不支持 if/else
验证与调试技巧
运行前先看实际合并结果，避免盲启：
- 用
docker compose config查看最终生效配置（会自动包含 override） - 加
--no-deps或--dry-run（v2.23+）预检启动流程 - 遇到覆盖失效？检查 YAML 缩进是否一致、服务名是否拼写完全相同、字段是否属于可覆盖类型
