合并多个 Compose 文件后，env_file 指向了错误目录

后端目录里明明有环境文件，单独使用后端的 Compose 配置也正常；把前端和后端配置通过多个 -f 合并后，Compose 却去仓库根目录找这个文件。若根目录恰好存在同名文件，还可能不报找不到文件，而是把另一套变量送进后端容器。

这种情况要核对的是合并后的路径基准。使用多个 -f 时，各文件里的相对路径统一相对于第一个 Compose 文件所在目录解析；后面的文件不会各自保留自己的目录基准。显式设置 --project-directory 时，则改用指定的项目目录。

下面针对 Docker Compose 命令行通过 -f 合并本地文件的场景。示例命令采用 Bash、Zsh 等 shell 的环境变量赋值语法；不涉及从标准输入读取配置，也不把这套规则直接套到 include。

同一个相对路径，单独使用和合并后的含义不同

假设目录如下，名称和镜像地址均为示例：

repo/
├── compose.yaml
└── backend/
    ├── compose.yaml
    └── backend.env

根目录的 compose.yaml 定义前端：

services:
  frontend:
    image: registry.example.com/team/frontend:1.0

backend/compose.yaml 定义后端：

services:
  backend:
    image: registry.example.com/team/backend:1.0
    env_file:
      - ./backend.env

在 repo/ 下，只指定后端配置进行校验：

docker compose -f backend/compose.yaml config -q

第一个配置文件位于 repo/backend/，因此 ./backend.env 对应 repo/backend/backend.env。

仍在 repo/ 下，把根目录配置放在前面：

docker compose -f compose.yaml -f backend/compose.yaml config -q

这次公共基准变成 repo/，后端的 ./backend.env 就指向 repo/backend.env。后端 YAML 所在位置没有变，但它参与合并的方式变了。

因此，仅确认文件“就在 YAML 旁边”还不够。需要拿实际部署命令中的第一个 -f、有没有 --project-directory，以及最终的 env_file 路径一起判断。

先查看解析后的路径，再选择改法

保留实际使用的全部 -f 及其顺序，在受控终端查看配置：

docker compose -f compose.yaml -f backend/compose.yaml \
  config --no-env-resolution

这里跳过服务 env_file 内容的展开，便于检查其路径；路径解析仍然开启。不要同时加 --no-path-resolution，否则正好跳过了这次要核对的步骤。

找到后端服务下的 env_file，确认它是否落在预期的 backend/ 目录内。不同 Compose 版本的输出形式可能不同，重点看路径本身。如果当前版本不认识 --no-env-resolution，先查看 docker compose config --help，不要把选项不支持误判成环境文件故障。

这份输出仍可能包含其他 environment 字段或插值后的凭据；跳过环境文件展开不等于输出已经脱敏，不要直接贴到公开日志。这个检查也没有验证环境文件能否完整读取，修正后还要运行普通的 config -q。

如果路径已经正确，错误却是权限不足或内容解析失败，就应继续检查该文件的读取权限和格式。不要为了改变目录基准反复移动文件。

只用于整体部署：直接写相对于根配置的路径

若后端配置从来不会独立使用，可以把它改为：

services:
  backend:
    image: registry.example.com/team/backend:1.0
    env_file:
      - ./backend/backend.env

前提是根目录的 compose.yaml 始终排在第一个 -f，且没有另设项目目录。这样合并后的路径就是 repo/backend/backend.env。

这项改动也改变了后端配置单独使用时的含义。若随后只运行 -f backend/compose.yaml，基准会回到 repo/backend/，路径就多了一层 backend/。需要同时支持单独运行和整体运行时，应采用下面的参数化写法，而不是把两个路径都放进 env_file 列表。

后端也要独立使用：由调用方传入目录前缀

把 backend/compose.yaml 中的路径改成：

services:
  backend:
    image: registry.example.com/team/backend:1.0
    env_file:
      - ${BACKEND_BASE:-.}/backend.env

BACKEND_BASE 是这里自行约定的变量名，不是 Compose 内置变量。${BACKEND_BASE:-.} 表示变量未设置或为空时使用 .。展开得到的路径仍然服从本次命令的公共目录基准。

在 repo/ 下合并前后端时，显式传入相对于根目录的前缀：

BACKEND_BASE=./backend docker compose \
  -f compose.yaml -f backend/compose.yaml config -q

同样在 repo/ 下单独校验后端时，让前缀为 .：

BACKEND_BASE=. docker compose -f backend/compose.yaml config -q

后一条命令显式赋值，是为了避免终端里先前设置的 BACKEND_BASE 干扰判断。此时第一个配置文件在后端目录，. 已经代表后端目录，不需要再加一层。

不要只把 BACKEND_BASE 写进正在寻找的 backend.env，期望它决定自身的位置。Compose 在读取服务环境文件之前就需要确定这个路径；用于路径插值的值应由调用环境等 Compose 插值来源提供。服务 env_file 的职责是向容器提供环境变量。

实际部署入口也必须采用相同的变量值、文件列表和顺序。只在校验命令前赋值，随后换成不带该变量的启动命令，仍会回到默认路径。把这组参数保存在项目既有部署脚本中，比依赖某个终端临时导出的变量更容易保持一致。

不要用全局目录变化修补一个服务

把后端文件挪到第一个 -f，确实会改变路径基准，但也改变合并顺序。后面的文件可能覆盖前面的配置，前端的相对路径也会随之改变。不能只看到后端环境文件能读取，就认定整个项目已经修好。

--project-directory 同样调整整个项目的基准，适合统一约定项目根目录，无法同时让前端相对于前端目录、后端相对于后端目录。尤其要检查绑定挂载和构建上下文，避免为了读一个环境文件而把数据目录指向另一处。

如果真正的需求是组合多个相互独立的 Compose 应用，可以另行评估 Compose 2.20.0 及以上的 include。它允许被包含的模型按自己的项目目录解析路径，但资源名称冲突不会像多个 -f 那样直接合并。已有项目依赖覆盖关系时，不能只替换语法就迁移。

修复后的检查与回退

先保存配置修改前的版本，并记录部署入口原有的文件顺序和项目目录。修改后，用同一组参数再次查看解析路径，然后运行 config -q：前者确认读取的是哪个文件，后者确认完整配置能够被解析和校验。只有不再报找不到文件还不足够，同名文件也可能来自错误目录。

若项目同时支持整体部署和后端独立部署，两种调用都应检查。完整配置校验通过也不代表应用已经连接到正确的数据库或服务；按现有发布流程应用改动后，还应检查应用自身的非敏感环境标识和健康状态，避免通过打印全部环境变量来验收。

需要回退时，恢复配置及部署脚本中的目录前缀，并按原有流程重新应用。不要通过删除数据卷或复制一份生产凭据到仓库根目录来掩盖路径错误；路径问题本身不需要清理容器数据。