Docker Desktop GUI不维护“当前Compose项目”状态，所谓当前项目由终端所在目录、-f参数或COMPOSE_PROJECT_NAME环境变量决定；docker compose ps仅显示当前目录下compose文件定义的容器，docker compose ls则列出所有通过docker compose启动过的项目名。
你无法直接从 Docker Desktop GUI 界面看到“当前正在操作哪个 Compose 项目”——它本身不维护一个全局的“当前项目”状态。所谓“当前项目”，完全由你在终端中执行 docker compose 命令时所处的目录 + 是否显式指定了配置文件决定。
为什么 docker compose ps 有时显示空，有时显示一堆容器？
因为 docker compose ps 默认只列出**当前工作目录下 docker-compose.yml（或 compose.yaml）所定义的项目中的容器**。它不会扫描所有运行中的容器，也不会自动关联到 Docker Desktop 左侧服务列表里你点开的某个服务。
- 如果你在
/projects/api目录下运行docker compose ps，它查的是/projects/api/docker-compose.yml - 如果你在
/tmp目录下运行同一命令，且该目录没有 compose 文件，就会报错no configuration file provided: not found或返回空 - Docker Desktop 左侧的“Containers / Apps”标签页里显示的服务名（如
api-web-1），其前缀（api-）通常来自项目名，而项目名默认是当前目录名，也可由-p参数或COMPOSE_PROJECT_NAME环境变量覆盖
如何快速确认当前终端命令作用于哪个项目？
最可靠的方式是组合查看三件事：当前路径、显式参数、环境变量。
- 先执行
pwd（macOS/Linux）或cd（Windows PowerShell/CMD），看你在哪个目录 —— 这是默认项目名和默认配置文件查找路径的来源 - 检查是否用了
-f：比如docker compose -f ../prod/docker-compose.yml up，那实际操作的就是../prod/下的项目 - 检查是否设了
COMPOSE_PROJECT_NAME：echo $COMPOSE_PROJECT_NAME（Linux/macOS）或echo %COMPOSE_PROJECT_NAME%（Windows CMD）；若存在，它会覆盖目录名作为项目名 - 想验证当前命令到底识别了哪个项目，加
--project-name查看解析结果：docker compose --project-name test config --resolve-image-digests 2>/dev/null | head -1（会输出类似name: test）
docker compose ls 显示的 “PROJECT” 列到底代表什么？
这是 Docker CLI v2.20+ 引入的命令，列出所有通过 docker compose 启动过的项目（不是所有容器）。它的 “PROJECT” 列 = 实际生效的项目名，即：
- 如果你没指定
-p且没设COMPOSE_PROJECT_NAME，那就是当前目录名（不含路径，只取 basename） - 如果你运行过
docker compose -p myapp up，那这里就显示myapp - 注意：这个列表**不包含**用
docker run启的单个容器，也不包含用旧版docker-compose（连字符）启动但未被新版 CLI 记录的项目 - 它依赖本地元数据存储（
~/.docker/compose/），重启 Docker Desktop 不清空，但重装或手动删掉该目录后会丢失历史记录
Windows 用户特别注意：WSL 与 PowerShell 的路径陷阱
在 Windows 上用 Docker Desktop + WSL 时，PowerShell 和 WSL 的当前路径可能完全不同，而 docker compose 命令的行为取决于**调用它的 shell 所在的路径**。
- 在 PowerShell 中执行
docker compose up，它读取的是 Windows 路径（如C:\dev\app），并自动映射进 Linux 容器 - 在 WSL 中执行同一命令，路径是
/mnt/c/dev/app，虽然内容一致，但项目名默认变成app（和 PowerShell 下一样），但某些挂载路径写法（如./data）在 WSL 下可能因换行符或权限导致失败 - 最稳妥做法：统一在 PowerShell 或 CMD 中操作，并确保
docker-compose.yml中的volumes使用相对路径（如./config:/app/config），避免硬写C:\或/mnt/c/
真正容易被忽略的一点：Docker Desktop GUI 里的“停止所有”按钮，停的是整个 Docker Engine 的容器，不是某个 compose 项目；而 docker compose down 只影响当前项目。两者作用范围不同，混用可能导致你以为“项目停了”，其实其他项目容器还在跑，或者反过来——误关了不该关的服务。
