docker compose config 是验证 docker-compose.yml 格式与语义合法性的最直接方式，它不启动容器，仅做静态校验，成功时输出规范化 YAML，失败时精准提示错误行和字段，并支持环境变量插值展开与版本兼容性检查。
docker compose config 是验证 docker-compose.yml 格式是否合法、语义是否可解析的最直接方式——它不启动容器，只做静态校验，出错时会明确告诉你哪一行、哪个键有问题。
用 docker compose config 快速验格式
VS Code 本身不内置 YAML 语义级校验能力，插件提供的语法高亮和补全只是表层。真正能发现 services.web.depends_on 写成 depends_onn、或 ports 缩进错两格这种问题的，还是靠 Docker CLI 自带的 config 命令。
- 在项目根目录终端运行
docker compose config，成功则输出规范化后的 YAML；失败则提示类似yaml: unmarshal errors: line 12: field depends_onn not found in type types.ServiceConfig - 加
--quiet可静默执行，适合集成进 pre-commit 或构建脚本 - 注意：必须确保
version字段值是当前 Docker Compose 支持的（如'3.8'或'2.24'），否则会报Unsupported config version - 如果使用了
extends或环境变量插值（${VAR}），config会尝试展开——此时需提前设置好环境变量，否则可能误报
VS Code 插件里开 Docker: Validate 开关
官方 Docker 扩展默认只做基础语法高亮，要启用结构校验得手动打开验证开关：
- 按
Cmd+,（Mac）或Ctrl+,（Win/Linux）打开设置，搜索dockerfile validate——别被名字误导，这个开关同时控制Dockerfile和docker-compose.yml的验证 - 勾选
Docker: Validate后，编辑器会在保存时自动调用docker compose config（前提是 CLI 可访问） - 错误会以波浪线+悬停提示形式出现，但不会阻断保存；若想严格拦截，需配合
pre-commit或husky - 该功能依赖本地
docker命令可用；WSL2 用户常因路径未加入$PATH导致验证失效，可检查docker --version是否能在 VS Code 集成终端中执行
为什么不用第三方 YAML Linter？
有人试过用 yamllint 或 VS Code 的 YAML 插件校验 docker-compose.yml，结果往往不准：
-
yamllint不理解compose特有字段（如deploy、profiles、x-*扩展），会把合法配置标为“unknown key” - 它无法识别
build.context路径是否存在、volumes挂载宿主机路径是否可读——这些只有docker compose config在解析时才能判断 - 不同 Compose 规范版本支持的字段差异大（比如
version: '2'不支持networks.driver_opts），通用 YAML 工具没法动态适配
容易忽略的三个细节
即使 docker compose config 通过，也不代表服务一定能跑起来：
-
depends_on只控制启动顺序，不等待依赖服务“就绪”——数据库容器可能已启动，但 MySQL 还没完成初始化，应用连接会失败；要用healthcheck+condition: service_healthy -
environment中的变量若来自.env文件，config不会报错，但拼写错误（如DB_PASWORD）会导致运行时空值，且无任何提示 - Windows 用户用 WSL2 时，
volumes路径写成C:\project\dist会被当成绝对路径挂载失败，必须用/mnt/c/project/dist格式，config不检查路径有效性
