[容器开发] Docker Desktop – 容器、Compose 与本地 Kubernetes 开发环境 | 多平台版

Docker Desktop 是面向 Windows、macOS 与 Linux 的本地容器开发环境。它把 Docker Engine、Docker CLI、Build、Compose、镜像与容器管理界面，以及可选的本地 Kubernetes 集成到一套桌面应用中。泡泡茶壶小编依据 Docker Desktop 4.84.0 官方发布说明、三平台安装文档、WSL 2 说明和订阅服务协议整理了这份介绍。

它解决的并不是“给 Docker 命令加一个界面”这么简单。桌面系统原本不能直接运行 Linux 容器，Docker Desktop 会管理所需的 Linux 虚拟化环境、网络、磁盘镜像、凭据和版本更新，再把统一的 docker 命令与 Dashboard 交给用户。便利来自这层托管，但内存占用、文件共享、磁盘增长和授权边界也都由此产生。

Docker Desktop、Docker Engine 和容器是什么关系

Docker Engine 是实际创建与运行容器的核心引擎，Docker CLI 负责发送命令，Compose 根据 YAML 文件组织多个服务；Docker Desktop 则把这些组件连同虚拟机、网络、存储、更新和图形界面打包成桌面产品。只安装 Docker Engine 与安装 Docker Desktop 并不是同一件事，前者更常见于 Linux 服务器，后者更适合个人电脑上的开发与测试。

Dashboard 可以查看正在运行或已停止的容器、镜像、Volume、Build 记录与扩展，也能检查日志、端口、环境变量和资源使用情况。它适合快速定位状态，但不会替代 Dockerfile、Compose 文件或命令行：可提交到代码仓库并在团队与 CI 中复现的，仍然是声明式配置，而不是某台电脑上的点击结果。

上图取自 Docker Desktop 官方产品页，用于展示桌面端集中管理开发环境的形态。具体导航、功能入口与附带组件会随版本和订阅计划变化，因此更值得掌握的是镜像、容器、Volume、网络和 Compose 之间的关系。

Windows 上选择 WSL 2 还是 Hyper-V 后端

Windows 上的大多数用户适合使用 WSL 2 后端。官方当前推荐的按用户安装模式默认使用 WSL 2，不需要管理员权限完成日常安装和更新；WSL 2 提供完整 Linux 内核、动态资源分配、较快冷启动与更顺畅的 Linux 工作区体验。Docker 命令可从 Windows 终端使用，也能为指定 WSL 发行版开启集成。

Hyper-V 后端的功能总体相近，但只有全用户安装模式可选，并涉及 Hyper-V 虚拟机管理。需要 Windows 容器、希望与 WSL 的共享内核模型隔离，或企业策略已经围绕 Hyper-V 部署时，才更有必要选择它。Windows Home 可以运行 Linux 容器；运行 Windows 容器则需要符合官方要求的 Professional 或 Enterprise 版本。

截至 2026 年 8 月 1 日，官方列出的 Windows 基线包括 WSL 2.1.5 或更高版本、开启硬件虚拟化、至少 8GB 内存，以及 Windows 10 22H2（build 19045）或 Windows 11 23H2（build 22631）以上版本。将项目放在 WSL 的 Linux 文件系统中，通常比跨 Windows 文件系统大量绑定挂载更适合依赖密集、频繁读写的小文件工作负载。

镜像、容器、Volume 与 Compose 怎样组成开发环境

镜像是只读模板，容器是镜像的一次运行实例。Dockerfile 记录基础镜像、依赖、文件与启动命令，docker build 把它构建成镜像，docker run 再创建容器。删除容器不会自动删除镜像；反过来，修改正在运行的容器也不等于更新了 Dockerfile，这种区分能避免把临时调试结果误当成可复现环境。

Volume 用于保存数据库、缓存或其他需要跨容器重建保留的数据，Bind mount 则把宿主机目录映射进容器，常用于源码热更新。端口映射把容器端口暴露给本机，网络让多个服务按名称互相访问。数据库数据若只写在容器可写层里，重建容器时就容易丢失；重要数据应明确进入 Volume，并建立备份或导出策略。

Compose 用一个 compose.yaml 描述应用、数据库、队列等多个服务的镜像、构建方式、网络、端口、环境变量和 Volume。docker compose up 可以按依赖启动整套环境，docker compose down 清理相关容器与网络。它的价值是把“我电脑上这样点出来能跑”变成团队成员和自动化流程都能复现的配置。

本地 Kubernetes 什么时候值得开启

Docker Desktop 可以在设置中创建本地 Kubernetes 集群，并配套提供 kubectl 与 Docker 网络、镜像工作流。它适合验证 Deployment、Service、Ingress、ConfigMap、Secret 等 Kubernetes 对象，或在提交到远程集群前检查 Helm Chart 和运维清单。需要模拟多个节点时，可按当前版本提供的集群选项选择相应方式。

普通的 Web 应用、数据库和缓存组合并不因为使用容器就必须启用 Kubernetes。只要 Compose 已能描述本地依赖，引入集群会额外占用 CPU、内存与磁盘，并带来命名空间、控制器、存储类和网络排查成本。文章教程或项目文档明确要求 Kubernetes，或生产交付目标本身就是 Kubernetes 时，再开启更合适。

本地集群也不能完全代表云端生产环境。负载均衡、持久化存储、身份权限、节点故障、GPU、网络策略和托管服务实现都会不同。Docker Desktop 更适合作为语法、镜像与部署流程的前置验证环境，而不是对生产容量、性能和高可用性的等价模拟。

资源、文件共享和数据清理为什么会影响体验

容器进程看起来轻量，但 Docker Desktop 背后仍有 Linux 虚拟机、镜像层、Build Cache、Volume 和可选 Kubernetes 组件。大型多阶段构建会快速占用磁盘，数据库 Volume 会持续增长，WSL 页缓存也可能暂时保留较多内存。Dashboard 的资源页面和 docker system df 可帮助判断空间消耗来自哪里。

清理前要区分可重建缓存与真实数据。未使用镜像和 Build Cache 通常可以重新拉取或构建，数据库 Volume 却可能包含唯一数据；不要把 docker system prune 或删除 Volume 当成无风险的常规按钮。重要项目应先确认 Compose 中的持久化位置，并备份需要保留的数据。

macOS 版当前支持最新及之前两个主要 macOS 版本，至少需要 4GB 内存，并分别提供 Apple 芯片与 Intel 安装包。Linux 版同样至少需要 4GB 内存、KVM 虚拟化支持和 QEMU 5.2 以上版本；它也会启动虚拟机并创建 desktop-linux context，因此可能与宿主机原生 Docker Engine 同时存在，执行命令前应确认当前 context。

免费使用不等于 Docker Desktop 是开源软件

Docker Desktop 采用 Docker Subscription Service Agreement，而不是把整个桌面产品作为开源软件授权。个人使用、教育、非商业开源项目，以及同时少于 250 名员工且年收入低于 1000 万美元的小型企业，可以按当前条款免费使用；更大型组织中的专业用途、政府实体及超出免费范围的商业使用，需要相应付费订阅。

这不意味着 Docker 生态全部变成闭源或收费。Docker Engine、Moby 等开源项目的授权不受 Docker Desktop 商业条款改变；需要判断的是组织是否在使用 Docker Desktop 这个桌面产品。公司设备部署前应由负责人核对当前协议、员工与收入门槛、集中管理及安全功能需求，不要只根据“安装包能免费下载”推断许可范围。

截至 2026 年 8 月 1 日，官方最新发布说明列出的版本为 Docker Desktop 4.84.0，发布日期为 2026 年 7 月 27 日。安装包持续滚动更新，Windows、macOS 与 Linux 的架构和体积不同；应从 Docker 官方产品页或对应平台安装文档下载，并在升级前查看发布说明中的系统要求、已知问题和安全修复。