docker compose up 直接报错时，日志有时已经混在容器启动信息里了。可以先在项目目录跑一遍：
docker compose config
docker compose config --quiet
前一条会输出合并、插值后的最终配置，适合检查 env_file、多份 compose 文件和变量替换；后一条只做校验，配置没问题时不输出内容，放进 CI 也比较干净。
环境：Docker Compose v2。命令默认读取当前目录的 Compose 文件；如果用了额外文件，记得用相同的 -f 参数传入。它只校验并渲染配置，不会创建或启动容器。
补一个容易忽略的点：config 会把变量插值后的结果展开，里面如果有密码或 token，别把完整输出直接打进 CI 日志。CI 只做校验时用 --quiet；本地排查也先对输出脱敏。多文件场景还要和实际 up 保持相同的 -f 顺序。
HosuLv1#1 补一个容易忽略的点：
config会把变量插值后的结果展开，里面如果有密码或 token，别把完整输出直接打进 CI 日志。CI 只做校验时用--quiet；本地排查也先对输出脱敏。多文件场景还要和实际up保持相同的-f顺序。
补个适合 CI 的用法：config --quiet 只负责返回校验结果；要比较多套配置，可以把最终结果按 JSON 导出来：
docker compose -f compose.yml -f compose.ci.yml config --format json > /tmp/compose.json
jq '.services | keys' /tmp/compose.json
环境：Docker Compose v2、jq。-f 顺序要和实际启动保持一致。导出的结果可能包含插值后的敏感值，临时文件和 CI 日志别直接公开。
这个检查更像配置层的门禁，不会验证镜像能不能拉下来、端口是否可用，或者服务能否健康启动。可以把它放在 CI 的配置校验阶段，后面再单独做启动和健康检查，避免把“配置合法”误当成“服务可用”。
还有个小坑：变量没设置时，有些写法会退化成空字符串，config --quiet 也可能照样通过。必须项可以写成 ${DB_HOST:?DB_HOST is required}，再跑 docker compose -f compose.yml config --quiet；缺变量时会直接非零退出。可选变量别加 :?，免得本地开发被卡住。
JonahLv1#4 还有个小坑：变量没设置时，有些写法会退化成空字符串，
config --quiet也可能照样通过。必须项可以写成${DB_HOST:?DB_HOST is required}，再跑docker compose -f compose.yml config --quiet；缺变量时会直接非零退出。可选变量别加:?，免得本地开发被卡住。
如果项目用了 profiles，CI 还要把实际部署会启用的 profile 带上，不然默认未启用的服务不会参与这次展开。比如：
docker compose --profile ci -f compose.yml config --quiet
本地和 CI 的 --profile、-f 顺序最好固定一致，不然校验通过的可能不是实际启动的那套服务。