Docker主要不是一个开发人员工具，而Compose的主要目标也不是加速开发人员环境。
事实上，Docker有几个核心特性似乎与将其用作开发环境相反。每个容器都有一个独立的文件系统，因此容器通常无法看到主机系统上的代码，主机系统也无法看到仅安装在容器中的工具。此外，容器基于不可变的映像：通常情况下，如果不重建映像并重新创建容器，就无法更改容器正在运行的代码。对于使用编译语言（C++、Java、Go、Rust）的开发人员来说，这是一个熟悉的工作流程，即使没有Docker，每次更改后，您仍然需要重新编译并重新启动应用程序。
这种更典型的不变映像设置的一个很好的例子是运行一个数据库容器。

docker run -d -p 5432:5432 -v pgdata:/var/lib/postgresql/data postgres:14

但是运行这个程序时你不需要下载PostgreSQL的源代码，在正常使用中你可以完全通过发布的端口与它交互。映像本身不包含任何源代码或构建工具。
除此之外，您还可以使用Compose构建由多个容器构建的大型应用程序;例如

version: '3.8'
volumes:
  pgdata:
services:
  db:
    image: postgres:14
    ports: ['5432:5432']
    volumes: ['pgdata:/var/lib/postgresql/data']
  app:
    image: registry.example.com/myapp:${MYAPP_TAG:-latest}
    ports: ['8000:8000']
    depends_on: [db]
    environment: {PGHOST: db}

同样，这种设置不依赖于任何可用的源代码;只要您有一个预构建映像，您就可以运行它。
特别是如果你有一个解释语言，你可以使用绑定挂载把你的本地源代码注入到镜像中的代码上。如果你这样做了，容器会运行你在主机系统上的代码。你经常会在基于节点的应用程序中看到这种情况

services:
  app:
    build: .
    ports: ['3000:3000']
    volumes:
      - .:/app             # replace everything in the image with local code
      - /app/node_modules  # hack: use an anonymous volume rather than host library tree

但是，即使这样，您也不能直接与容器中的工具交互。我看到一些关于希望使用基于Docker的设置而不是基于主机的工具的SO问题，如果您不介意将所有内容都 Package 在某种docker调用中，那么您可以这样做

# doesn't work if yarn isn't installed locally
yarn add somelib

# uses the yarn in the `node` image, but long-winded
docker-compose run app \
  yarn add somelib

这确实导致了Docker映像的一种风格，它只是一个工具的集合，其中没有任何特定的应用程序。例如。您可以将这些容器插入到Jenkins这样的CI工具中，Jenkins知道如何执行所有绑定挂载，并使其看起来像是在处理正在构建存储库。
开发容器与此类似。特别是如果您使用Visual Studio代码，它们将允许您使用容器外的工具来开发应用程序。您可以使用devcontainer.json文件启动多个容器，但这不一定是主要用例;通常期望您有一个工具容器，但 * 不 * 将应用程序嵌入到映像中。据我所知，它与VSCode绑定，不一定在其他上下文中可用，在其他上下文中，您也可以使用Compose或普通Docker进行生产部署。