Compose 文件改完后，不一定要直接启动一堆服务。可以先让 CLI 只做配置解析和变量替换校验：
环境：Docker Compose v2，在包含 compose.yaml 的目录执行。
mkdir compose-check-demo && cd compose-check-demo
printf '%s\n' \"services:\" \" web:\" \" image: nginx:alpine\" \" ports:\" \" - \"\"${WEB_PORT:-8080}:80\"\"\" > compose.yaml
WEB_PORT=8088 docker compose config --quiet
echo $?
退出码为 0 就表示配置能被 Compose 解析；端口写错、YAML 缩进不对或变量格式有问题时，会在真正启动前报出来。想看变量替换后的完整配置，可以去掉 --quiet。
它只检查配置，不会拉镜像，也不会创建容器，放进提交前检查或 CI 里挺省事。
这个很适合放进 CI。再补一个容易漏的点：${API_URL:?API_URL is required} 这种必填变量写法，能避免变量没注入时被静默替换成空字符串。config --quiet 通过也只代表配置能解析，健康检查、端口冲突和容器启动后的问题还得交给后续步骤。
补充个 CI 里挺实用的细节：如果只是想把它当校验步骤，可以直接用 docker compose config --quiet && echo 'compose config ok'，失败时保留 CLI 的退出码，别被后面的日志覆盖。多环境配置则显式加 --env-file，这样检查的变量来源和实际部署更一致。
还有个边界：如果配置里用了 env_file，config --quiet 主要验证 Compose 能否解析和展开配置，不等于文件里的每个值都符合应用要求。CI 里可以先固定一份最小 .env.ci，再配合应用自己的启动校验；这样缺变量时更早失败，也不会把开发机环境带进检查。
Nathan03Lv1#4 还可以把
config --quiet放到合并请求的第一步，后面的镜像构建和测试用needs依赖它。这样 YAML 或变量问题会更早反馈，而且不会先消耗构建时间。若同时传多个-f文件，也建议用和部署完全相同的文件顺序做校验，覆盖关系不一致时结果会误导。
再补一个 profiles 的坑：如果部署时会启用某个 profile，校验时也要带上同样的 --profile 参数。否则被 profile 过滤掉的服务可能没有进入这次检查，CI 通过了，实际启动那组服务时才暴露问题。多环境下最好把 compose 文件、env-file 和 profile 参数都由同一份部署配置生成。