docker-compose config 命令直接输出合并后配置，不启动容器，仅解析并展开所有文件（含 -f 指定的多文件）、环境变量和 .env 文件，生成 Docker 引擎实际读取的最终 YAML；图形界面“Compose”标签页仅为原始文件预览，不解析变量或合并覆盖。
docker-compose config 命令直接输出合并后配置
想看 Docker Desktop 里 docker-compose.yml 经过所有覆盖、环境变量、.env 文件替换后最终生效的配置，最可靠的方式就是用命令行跑 docker-compose config。它不启动容器，只做配置解析和合并，输出的是 Docker 引擎实际读取的 YAML。
常见错误是以为图形界面里点“Compose”标签页就能看到合并结果——其实那只是原始文件预览，没展开变量、没加载 override、也没校验语法。
- 确保当前目录下有
docker-compose.yml（或通过-f指定） - 如果用了多文件（如
docker-compose.prod.yml），加上-f参数：docker-compose -f docker-compose.yml -f docker-compose.prod.yml config - 想看带注释和格式的可读版本，加
--pretty（Docker Compose v2.20+ 支持） - 遇到
environment里变量未展开？检查.env文件是否在当前目录，且变量名拼写与${VAR_NAME}一致
Windows 下 WSL2 后端导致的路径/环境变量差异
Docker Desktop 在 Windows 上默认走 WSL2，这意味着 docker-compose config 实际是在 WSL2 的 Linux 环境中执行的。你本地 Windows 的环境变量（比如 PowerShell 里的 $env:MY_VAR）不会自动透传过去，只有 .env 文件或 docker-compose.yml 中硬编码的值才生效。
典型现象：你在 CMD 或 PowerShell 里 set MY_VAR=abc，然后运行 docker-compose config，但输出里 ${MY_VAR} 还是原样没替换。
- 解决方案：把变量写进项目根目录的
.env文件，格式为MY_VAR=abc（不能有空格、不能用引号包裹） - 注意
.env文件只影响environment:和ports:等字段，不影响build.context这类路径字段 - 如果必须用 Windows 环境变量，可临时切换到 WSL2 终端执行：打开 Ubuntu（或其他已安装发行版），
cd /mnt/d/path/to/project，再运行docker-compose config
docker-compose.override.yml 不生效的三个常见原因
docker-compose.override.yml 是自动加载的，但很多情况下它看起来“没起作用”，本质是加载逻辑被忽略或覆盖了。
- 文件名必须严格为
docker-compose.override.yml，少一个字母、多一个空格、或者叫override.yml都不会被识别 - 只在
docker-compose up或docker-compose config时自动加载；单独运行docker run完全不读它 - 如果用了
-f显式指定文件（如docker-compose -f docker-compose.prod.yml config），则override.yml被跳过——此时需手动加回去：docker-compose -f docker-compose.prod.yml -f docker-compose.override.yml config
图形界面里看不到最终配置，别信“Compose”标签页
Docker Desktop 的 GUI 界面里，“Compose”标签页只是把 docker-compose.yml 当作纯文本展示，不做任何解析。它不会展开变量、不合并 override、不校验语法，甚至不检查字段是否合法（比如写个错别字 port: 也不会报错）。
真正要验证配置是否能跑通，唯一靠谱方式还是命令行：
-
docker-compose config→ 看合并后结构 -
docker-compose config --quiet→ 静默模式，只返回 0（成功）或非 0（失败），适合 CI 脚本 -
docker-compose up --dry-run（v2.21+）→ 模拟启动流程，检查网络、卷、依赖是否就绪
图形界面的价值在于启停容器、查看日志、监控资源，而不是替代配置验证。把这两件事混在一起，是多数人配置出错却找不到原因的起点。
