Docker Compose 默认自动合并 docker-compose.yml 与 docker-compose.override.yml，因未加 -f 时隐式执行 -f docker-compose.yml -f docker-compose.override.yml；该机制仅识别这两个全小写、同目录的固定文件名，其他如 compose.dev.yml 需显式指定。
直接用 docker compose -f 指定多个文件，顺序决定覆盖逻辑——不是“一起加载”，而是“从左到右依次合并”，右边的配置能改掉左边的。
为什么 docker-compose.yml 和 docker-compose.override.yml 会自动合并？
Docker Compose 在没加 -f 时，默认行为是隐式执行 docker compose -f docker-compose.yml -f docker-compose.override.yml。这个机制只认这两个固定文件名，大小写必须全小写，且必须在当前目录下。其他名字（比如 compose.dev.yml）不会被自动识别，哪怕你把它放在同一目录里。
-
docker-compose.override.yml是为本地调试设计的，比如挂载源码、开 debug 端口，它不该进 Git —— 所以建议加进.gitignore - 如果你同时有
docker-compose.yml和docker-compose.prod.yml，又想跳过 override，就必须显式列出：docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d，否则 override 会悄悄混进来 - Windows 上注意路径分隔符：YAML 里写
./src:/app或.\src:/app都行，但别用单反斜杠\（会被 YAML 解析器当成转义）
ports、environment、deploy.resources 合并规则完全不同
同名字段不是统一覆盖或统一追加，不同字段类型行为差异很大，搞错就容易漏端口、丢环境变量、或资源限制失效。
-
ports、volumes、depends_on：列表类字段，所有条目都保留，base写了["8080:80"]，dev加了["3000:3000"]，最终两个端口都暴露 -
environment：键值对深度合并，base设ENV=prod，dev设ENV=dev，最终生效的是dev；但dev没写的变量（如DB_HOST）仍沿用base的值 -
deploy.resources、healthcheck、command：整块替换，prod文件里只要写了deploy:块，不管里面有没有写全字段，都会把base中整个deploy块顶掉
Windows 上启动多文件组合常遇到的三个实际卡点
不是语法问题，而是 Docker Desktop + WSL2 环境下的路径、权限和加载时机问题。
- WSL2 集成没开：Docker Desktop 设置 → Resources → WSL Integration 必须勾选你正在用的发行版（如
Ubuntu-22.04），否则docker compose能运行，但卷挂载失败、depends_on超时 - 文件路径不在 WSL2 可见区：把
docker-compose.yml放在C:\Users\xxx\project\下没问题，但放在C:\Program Files\或 OneDrive 同步目录里，WSL2 可能读不到，报ERROR: failed to read docker-compose.yml -
docker compose config报错却没提示具体哪一行：先检查缩进——必须用空格，不能用 Tab；再确认冒号后有空格（image: nginx✅，image:nginx❌）；最后验证文件名是否为全小写docker-compose.yml，Windows 资源管理器有时会显示为大写但实际是小写，终端里ls一眼可见
最易被忽略的一点：多文件组合后，docker compose config 输出的是最终合并结果，但它不校验镜像是否存在、端口是否被占、卷路径是否有读写权限——这些只有 up 时才暴露。所以别只信 config 成功，一定要 up -d 后立刻 logs 看输出。
