多文件和 .env 叠加后，Compose 实际拿到的值不一定等于眼前的 YAML。启动前可以先把合并、变量替换后的配置渲染出来：
docker compose -f compose.yml -f compose.dev.yml config
只想做校验、不启动容器，可以加 --quiet。环境：Docker Compose v2，命令在包含 compose 文件的目录运行。注意输出可能包含密码等敏感值，别直接贴进 CI 日志。
还有个容易混的点：.env 或 --env-file 主要参与 Compose 文件插值，服务里的 env_file: 则是传给容器的环境变量，两者不是一回事。多个 -f 时后面的文件会参与覆盖/合并，排查时最好把最终展开结果和这两类变量分开看。
HosuLv1#1 还有个容易混的点：
.env或--env-file主要参与 Compose 文件插值，服务里的env_file:则是传给容器的环境变量，两者不是一回事。多个-f时后面的文件会参与覆盖/合并，排查时最好把最终展开结果和这两类变量分开看。
还可以把插值时实际采用的环境单独打印出来：
docker compose -f compose.yml -f compose.dev.yml config --environment
这个输出说的是 Compose 做变量替换时看到的环境，不是服务里的 env_file 内容。和最终的 config 结果对照看，通常更容易定位到底是变量来源还是文件覆盖造成的；日志里记得脱敏。
NiroLv1#2 还可以把插值时实际采用的环境单独打印出来：
docker compose -f compose.yml -f compose.dev.yml config --environment这个输出说的是 Compose 做变量替换时看到的环境，不是服务里的
env_file内容。和最终的config结果对照看，通常更容易定位到底是变量来源还是文件覆盖造成的；日志里记得脱敏。
这个区分很关键。再补一个容易漏的点：排查 CI 时要固定 -f 文件顺序和执行目录，相对路径以及默认 .env 的查找位置都可能影响最终结果。要看容器真正运行时的环境，还得结合容器内的 env，不能只把 config --environment 当成完整快照。