同事机器上敲 docker compose，有时会提示找不到配置。仓库里文件名还是 docker-compose.yml，很容易怀疑是名字写旧了，还是命令入口已经换过。把官方认的名字和入口核对清楚，接着确认是不是跑在别的工作目录里，往往比怀疑 YAML 写错更接近原因。
How Compose works 写明：默认路径是工作目录里的 compose.yaml（首选）或 compose.yml。为了兼容更早的版本，也仍然支持 docker-compose.yaml 和 docker-compose.yml。两份同时存在时，会优先采用规范名 compose.yaml。所以仓库里只保留旧名，一般仍能被找到。若工作目录里另外还有 compose.yaml，实际生效的是后者，旧文件不会被当成首选。查找范围是当前工作目录，在别的路径下执行，即使仓库里有这份配置，也可能对不上。该页还提到，可以用自定义项目名覆盖默认名称，让同一份 compose.yaml 在同一套基础设施上部署两次，而不必改文件内容。多个描述也可以合并成一个应用模型，相对路径按第一份的父目录来解析。可用 fragments 和 extensions 压缩重复段落，也可以用 include 引入由其他团队维护的部分。这些写法都不改变默认文件名在工作目录里怎么解析。因此，继续使用 docker-compose.yml 并不等于现行工具已经不再识别它。更容易对不上的是这两处。一是当前目录里同时出现了规范名，旧名会被排到后面。二是有的机器还在调用独立二进制的连字符写法，有的机器用的是带空格的插件入口，两边给出的提示就不一样。
命令这一侧，该页把现行用法写成 docker compose 加子命令，例如 docker compose up、down、logs、ps。若使用 Docker Desktop，Compose CLI 默认已经包含在内。安装概览 把获取途径分成三种：推荐安装 Docker Desktop（其中已包含 Compose，也带有作为前置的 Engine 和 CLI），它可用于 Linux、Mac 和 Windows，装好之后可在菜单的 About Docker Desktop 里查看版本。Linux 上若这两项已经备齐，可以再装 Docker Compose 插件，这一途径仅适用于该系统。另外还有 Standalone（Legacy）。官方对独立安装的定性是不推荐，只为向后兼容而保留。Standalone 说明 还写清：独立二进制用的是 -compose 这种形式，要输入 docker-compose up，而不是当前标准的 docker compose up，并且只应用于兼容旧环境。只有在无法改用 Desktop 或插件时，才考虑这条独立二进制。若同事机器上敲的是带空格的 docker compose，对应的是 Desktop 或插件这条线，和旧的独立入口不是同一套。Compose 概览 把它定义为用一份 YAML 来描述并运行多容器应用的工具，并列出启动、停止、重建服务、查看状态、跟踪日志，以及在某个服务上执行一次性任务这些生命周期操作。Compose file reference 则把现行推荐的格式指向 Compose Specification，旧的 2.x、3.x 文件格式已经合并进该规范，由 1.27.0 及以上的 Docker Compose CLI（也称为 Compose v2）实现。这里只用来说明「现行格式」的指向，不展开字段细节，也不把文件格式版本和前面那个带连字符的入口混成一件事。
这和站内那篇 Podman 与 Docker 容易混的几处 不是同一问法：那边谈的是引擎和守护进程的心智，这里只关心 Compose 的文件名与命令。
你那边是工作目录里同时放了两份不同名的配置，还是有的机器还在调用带连字符的旧入口？