Compose 2.19 的 run --no-deps 仍报依赖 disabled：核对构建分支回归

CI 原本用 docker compose run --rm --no-deps test 执行代码检查，升级 Compose 后却在运行前报错：

service postgres is required by test but is disabled. Can be enabled by profiles []

如果实际版本是 Compose 2.19.0 或 2.19.1，目标服务使用 build，而被点名的依赖甚至没有 profiles，应检查旧版 run --no-deps 的处理顺序问题。不要因为错误中有 profiles，就给整个项目添加 profile 或删除真实依赖。

这个特定问题的修复已进入 Compose 2.20.0：先应用 --no-deps 的服务筛选，再选择和修改运行目标，避免后续处理把已经移除的依赖关系带回来。同样的错误也可能来自合法的 profile 约束，升级不会修复所有依赖配置。

先分清版本回归和确实未启用的依赖

以下只读命令要保留 CI 原来的文件、项目名和环境文件参数；名称是示例：

docker compose version
docker compose -f compose.yaml -p ci-check config

记录实际 Compose 插件版本，不只看 Docker Engine 或 Desktop 版本。CI 下载了独立插件、用户目录又放着另一份插件时，本机和流水线可能调用不同版本。完整 config 可能包含展开的凭据，在受控终端查看，不直接上传日志。

重点核对目标服务的 build、depends_on 和依赖服务的 profiles。目标已在 run 命令中明确指定、依赖没有 profile，却在旧版构建分支被说成 disabled，符合这次回归的范围。错误中的空列表 [] 是线索，不能单独证明原因。

如果依赖实际属于另一个未启用的 profile，普通 up 的模型可能确实无效。按部署意图启用对应 profile，或调整共同依赖的分组。这条配置路径与旧版 run --no-deps 回归应分别处理，尤其不要把所有较新版本的相同报错都归到 2.19 的缺陷。

使用包含修复的受支持版本

升级前保存 Compose 文件、流水线配置和插件安装方式，先在隔离的 CI 环境验证当前受支持版本。2.20.0 是这项修复进入发布的历史边界，不是要求现在安装这个旧版本。

仍使用原来的项目参数和目标命令验证。例如下面只适合确实不需要数据库的格式检查任务，前提是镜像中已提供 black 和所列项目目录：

docker compose -f compose.yaml -p ci-check run --rm --no-deps test \
  black --check app/ tests/

run 会创建新的临时容器，并沿用服务的挂载、入口等配置；传入的命令覆盖服务 command，但不会自动移除 entrypoint。确认入口脚本本身也不依赖数据库。--no-deps 只是不启动关联服务，不会让需要数据库的迁移或集成测试自动变成独立任务。

构建步骤还可能执行 Dockerfile 中的命令、访问软件源或写入缓存。核对 CI 使用的代码和挂载，避免把测试入口指向生产数据。--rm 删除退出后的临时容器，不删除服务挂载卷中的写入。

预先 build 不是可靠的统一绕过办法

拆成先 docker compose build test、再 run --no-deps，有些配置可以绕开失败分支，但不能保证成功。项目名改变会改变默认生成的镜像名称；前一次构建与后一次 run 使用不同的 -p，可能根本不是同一个镜像引用。旧版的处理顺序问题也不能靠“看到 build 完成”就判定消失。

需要暂时分开构建与运行时，核对同一组文件、项目名和明确的 image 引用，并在隔离环境验证实际入口。不要改成 docker run 后漏掉 Compose 中的卷、用户、环境变量和入口配置，也不要长期降级到旧插件当作最终修复。

验收应包括代码检查实际执行、退出码符合结果，并且没有为了绕过错误新启动数据库依赖。只看到 Compose 不再报 disabled，不能证明检查命令已经跑过。

升级若引入其他兼容问题，恢复保存的安装和流水线配置，同时记录仍未解决的旧版限制。插件回退不会撤销构建缓存或挂载目录中的更改；无需清空 Docker 数据目录，也不应使用 down -v 处理这个配置阶段错误。