在 Windows 上跑 Docker早几年最顺手的方案是装 Docker Desktop 的 Hyper-V 后端。但用过的人都知道Hyper-V 一开整个系统像背了个沙袋虚拟机管理器的开销明晃晃挂在那内存动不动被吃掉好几个 G笔记本风扇转得跟飞机起飞似的。后来 Docker Desktop 默认切到 WSL 2 后端Windows 下跑容器的体验才算真正轻下来——容器跑在 WSL 2 的轻量虚拟机里和 Windows 共享内核调度启动快、占用小、和本地文件系统交互也自然。这篇文章就用 WSL 把 Docker 从零搭起来覆盖环境准备、安装选型、核心配置、常用容器部署以及一堆我在实际部署中踩过的报错和排查思路适合想在 Windows 上低成本跑 Docker 的开发者、测试和运维朋友参考。1. 为什么把 WSL 当成 Docker 的底座先搞清这几层关系很多人第一次听说WSL 装 Docker会有点绕Docker 不是装 Windows 版吗怎么又扯上 WSL 了这里得把几层关系捋清楚后面配置才不会晕。1.1 Docker Desktop 与 WSL 2 的分工逻辑Docker Desktop 在 Windows 上其实是一个壳壳里面真正负责跑容器的是一个 Linux 虚拟机。早前这个虚拟机基于 Hyper-V现在默认基于 WSL 2。WSL 2 本身就是微软做的一个轻量虚拟机底层是真正的 Linux 内核不是翻译层。Docker Desktop 做的事情是把你 Windows 里的 Docker 命令行、图形界面转发到这个 WSL 2 虚拟机里由虚拟机里的 containerd、dockerd 去实际创建和运行容器。所以可以这样理解WSL 2 是地基Docker 引擎是房子。Windows 上你敲docker ps实际上是在和一个跑在 WSL 2 里的 Linux Docker 引擎通信。也正因为 Docker 引擎在 Linux 里跑所有镜像、容器、网络模型都是原生 Linux 环境和服务器上的 Docker 行为完全一致开发环境和生产环境之间的差距被压到最低。1.2 WSL 1 和 WSL 2 的差别为什么必须用 WSL 2WSL 有两个大版本。WSL 1 是把 Linux 系统调用翻译成 Windows 系统调用没有真正的 Linux 内核WSL 2 则是跑一个完整的轻量虚拟机里面有原生 Linux 内核。对 Docker 来说WSL 1 基本没法用——Docker 引擎依赖 cgroups、namespaces、overlayfs 这些内核特性WSL 1 的翻译层扛不住。所以现在装 Docker Desktop 时它会强制要求 WSL 2 内核开启。如果你机器上还留着旧版 WSL 1 的发行版建议直接删除重装或者升级到 WSL 2。判断某个发行版用的是哪版 WSL终端里执行wsl --list --verboseVERSION 那列是 2 就没问题是 1 的可以执行wsl --set-version 发行版名 2做转换转换过程要几分钟耐心等。1.3 和纯 Hyper-V 方案、VirtualBox 方案对比再说说为什么这套组合值得用。之前常用的方案无非三种方案优点缺点Docker Desktop Hyper-VWindows 原生支持Docker 官方维护系统整体占用高必须开启 Hyper-V 导致其他虚拟机软件受限Docker Desktop WSL 2启动快、内存按需分配、文件互访方便需要对 WSL 2 有一定了解排错时多了一层VirtualBox 里跑 Linux 再装 Docker隔离彻底、可完全自定义管理成本高性能和体验断档不能直接用 Windows 侧 Docker CLI实测下来WSL 2 后端的启动速度明显比 Hyper-V 后端快冷启动一个容器基本 1 秒内完成而且 WSL 2 的内存是动态占用容器不忙时不会吃掉全部配额。日常开发、本地中间件模拟、CI 脚本验证这套组合是最省心的这也是我推荐它的核心原因。2. 从零搭建WSL 环境准备与 Docker Desktop 安装标题叫快速部署但该做的准备一步都不能省。跳过环境检查和版本确认后面报错会教你做人。下面按我实际操作的顺序来。2.1 开启 Windows 功能与 WSL 2 内核更新第一步打开控制面板 - 程序和功能 - 启用或关闭 Windows 功能勾选以下三项适用于 Linux 的 Windows 子系统虚拟机平台虚拟机监视程序平台Windows 10 某些版本需要Windows 11 一般不需要勾完重启系统。接着以管理员身份打开 PowerShell执行wsl --install这个命令在较新的 Windows 10/11 上会自动安装 WSL 2 内核并设置默认版本为 2。如果执行完提示需要手动下载内核去微软官方文档的 WSL 页面下载wsl_update_x64.msi安装即可。装完验证一下wsl --status看到默认版本2之类的输出就说明基础环境就绪。2.2 安装发行版与迁移到非系统盘wsl --install默认会装 Ubuntu通常是当前 LTS 版。如果系统盘空间紧张建议把发行版放到其他盘。这一步很多人忽略等 WSL 的 VHD 镜像长到几十 G 才想起来挪那时候就要用导出导入过程略麻烦。先查看当前已安装的发行版wsl --list --verbose然后导出、注销、再导入到目标目录wsl --export Ubuntu D:\wsl\ubuntu.tar wsl --unregister Ubuntu wsl --import Ubuntu D:\wsl\ubuntu D:\wsl\ubuntu.tar --version 2注意--import之后默认以 root 登录且默认用户不是原来的普通用户。需要用ubuntu.exe config --default-user 用户名恢复默认用户或者编辑/etc/wsl.conf设置[user] default用户名。新装发行版就不存在这个问题直接开箱。安装完成后进入 WSL 里确认一下内核版本uname -r cat /etc/os-release内核版本至少在 5.10 以上Docker 用起来才顺手。2.3 Docker Desktop 安装选项与 WSL 集成设置去 Docker 官网下载 Docker Desktop Installer.exe 安装。安装过程中有一步是选择使用的后端务必勾选Use WSL 2 based engine。如果漏勾了装完也可以在 Settings General 里勾回来。装完打开 Docker Desktop进入 Settings Resources WSL Integration这里会列出所有已安装的 WSL 发行版。默认情况下Docker Desktop 只集成默认发行版。如果你希望某个发行版里也能直接用 Docker CLI就把对应的开关打开。我习惯把Ubuntu打开这样我进入 WSL 的 Ubuntu 终端后直接敲docker就能用不需要在 WSL 里再装一遍 Docker 引擎因为引擎是共享的。还有一个常被忽略的点Docker Desktop 自带的 CLI 工具路径在 Windows 侧是C:\Program Files\Docker\Docker\resources\bin里面包含docker.exe、docker-compose.exe。WSL 集成打开后WSL 内的/usr/bin/docker其实是一个客户端包装它会自动和 Windows 侧的 Docker Desktop 通信。所以 WSL 里不需要apt install docker.io装了反而可能出现版本不一致的混乱我见过好几个同事因为这个排查半天。3. 装好之后的三个关键配置镜像源、资源上限、存储位置Docker Desktop 装完就能用但能用和好用之间差着三个配置。这三件事我每次在新机器上配 Docker 都会做属于典型的过来人经验。3.1 镜像加速配置在国内网络环境下拉镜像慢是很普遍的问题。Docker Desktop 的镜像源配置在 Settings Docker Engine 里JSON 配置里加registry-mirrors字段{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com ] }保存后 Docker 引擎会重启。注意不同镜像加速地址的可用性会变化建议不要只填一个。另外提醒一句不要轻信网上随便给的加速地址优先选知名云服务商或开源社区维护的镜像源。配置好之后拉一个大镜像试试速度比如docker pull mysql:8.0明显变快就说明生效了。3.2 .wslconfig 的资源控制Docker Desktop 虽然能看到内存/CPU 设置但 WSL 2 整体资源伸缩范围其实由C:\Users\用户名\.wslconfig控制。这个文件是全局生效的不只影响 Docker还影响所有 WSL 发行版。我的一份经典配置如下[wsl2] memory6GB processors4 swap2GB localhostForwardingtruememory设置 WSL 2 虚拟机最大能拿多少内存processors限制可用 CPU 核数swap是交换分区大小。这里要特别说明WSL 2 默认会占用主机最多 50% 的内存如果主机是 32G 内存WSL 2 理论上最高可以吃 16G对开发机来说太吓人了。所以显式限制 memory 非常有必要宁可偶尔不够用再调大也不要让它无声无息吃满内存。改完.wslconfig后需要执行wsl --shutdown让配置生效然后重启 Docker Desktop。3.3>{ data-root: D:\\docker-data }保存后 Docker 会用新目录存数据。旧目录的数据需要提前docker save导出或者在停机状态下直接拷贝但更稳妥的做法是把旧数据删掉重新拉镜像因为大多数场景下镜像拉取比重建数据成本低。第二定期压缩 VHD。操作流程wsl --shutdown # 打开磁盘管理找到 docker_data.vhdx 对应的虚拟磁盘 # 或者用 diskpart 执行 compact更省事的方法是直接在管理员 PowerShell 里跑 diskpart 的 compact 命令或者用 Optimize-VHD。我个人的习惯是每个月做一次先docker system prune -a清理悬空镜像和未使用数据然后wsl --shutdown再压缩 VHD。4. 实战在 WSL 里跑 MySQL 和 Redis验证 WSL 后端配置讲再多不如跑两个容器来得直接。这里选 MySQL 和 Redis 是因为它们是最常见的本地中间件几乎每个后端项目都离不开。这两个容器跑起来WSL 后端的网络、卷、端口映射也就全验证了。4.1 MySQL 8.0 容器部署先创建一个自定义网络方便后面容器用容器名互访docker network create dev-network再跑 MySQL 容器docker run -d \ --name mysql-dev \ --network dev-network \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDroot123 \ -v mysql-data:/var/lib/mysql \ mysql:8.0解释一下关键点-v mysql-data:/var/lib/mysql是把 MySQL 的数据持久化到 Docker 卷里容器删了数据还在。如果忘了加这行容器一删数据库内容全没这个坑我踩过不止一次。-e MYSQL_ROOT_PASSWORD是初始化 root 密码的快捷方式第一次启动时生效。启动后验证docker ps docker exec -it mysql-dev mysql -uroot -proot123 -e SELECT VERSION();从 Windows 侧验证端口映射用 Windows 的命令行工具连 MySQL或者直接用浏览器访问localhost:3306看是否能通。WSL 2 的localhostForwarding默认开启所以 Windows 的localhost:3306可以直接转发到 WSL 里的容器端口这比早期 WSL 1 时代要手动配端口转发舒服太多。4.2 Redis 主从部署单机 Redis 不过瘾顺便把主从也搭起来顺便验证自定义网络的容器名互相解析能力。先拉镜像docker pull redis:7起主节点和从节点docker run -d --name redis-master --network dev-network -p 6379:6379 redis:7 redis-server --appendonly yes docker run -d --name redis-slave --network dev-network -p 6380:6379 redis:7 redis-server --slaveof redis-master 6379注意从节点的--slaveof用的是容器名redis-master这正是自定义网络里 Docker DNS 的功劳。如果两个容器都在默认网络也能通过容器名访问但自定义网络更干净而且可以和 MySQL 等容器一起管理。进入从节点验证主从状态docker exec -it redis-slave redis-cli INFO replication看到role:slave和master_link_status:up就说明主从建立成功。整个部署过程中你可以在 Docker Desktop 的仪表盘里实时看到容器状态和资源占用WSL 后端的启动速度在这里体现得很直观——容器秒级起停不会有任何拖沓感。4.3 从 Windows 访问容器服务前面提过localhostForwardingtrue让 Windows 可以直接访问 WSL 里的服务。但我需要提醒一点如果你改了.wslconfig里的localhostForwardingfalse或者有人在 remote 环境访问那就得改用 WSL 虚拟机的 IP 地址。查看这个地址可以进入 WSL 执行hostname -I然后用浏览器或客户端访问http://WSL-IP:端口即可。另外Windows 防火墙偶尔会拦截外部设备比如手机或另一台电脑访问 WSL 里的服务这时候需要在防火墙里放行对应端口。这是很多人在局域网联调时突然发现连不上的最常见原因。5. 高频报错排查链路从容器对象访问被拒绝到daemon 起不来WSL 配 Docker 多数问题集中在安装阶段和启动阶段。我把网上高频提问的热词收集了一遍整理成几个典型排查链路每个都给出可复现的操作过程。5.1 WSL 安装组件存储已损坏如何修复Windows 更新或者第三方工具清理系统文件时可能把 WSL 组件搞残。典型症状wsl --install报错、wsl命令无响应或者打开 WSL 终端提示安装组件存储已损坏。这个问题的排查链路比较固定第一步以管理员身份运行 PowerShell执行wsl --status如果能输出正常状态说明 WSL 内核没问题问题多在某个发行版上如果直接报错则先修 WSL 组件。第二步修复组件存储。在 Windows 10/11 上先尝试sfc /scannow dism /online /cleanup-image /restorehealth这两个命令执行耗时较长SSD 上大约 10 到 30 分钟耐心跑完。跑完重启再试wsl --status。第三步如果系统文件检查没用就重装 WSL 本身。先卸载当前 WSLwsl --uninstall然后重新wsl --install这里补充一句wsl --uninstall不会删除已经导入的发行版数据所以不用担心数据丢失。如果你的发行版是通过--import导入到其他盘的重新安装 WSL 后还需要重新执行一次wsl --import注册或者用wsl --attach之类的操作恢复。第四步仍不行就在启用或关闭 Windows 功能里取消适用于 Linux 的 Windows 子系统和虚拟机平台重启再重新勾选、重启。这个步骤会强制系统重新配置相关组件成功率很高。5.2 Docker Desktop 启动失败提示 virtualization support not detected这个报错直译是未检测到虚拟化支持。常见误区是一看到这句话就以为是 WSL 坏了其实根源往往是主板 BIOS 里的虚拟化开关被关了或者 Windows 的虚拟机监控程序没有生效。排查顺序第一检查 Hyper-V 是否开启systeminfo看输出里的 Hyper-V 要求部分如果四个选项都是是说明系统层面虚拟化可用如果显示已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能这是 Hyper-V 正在运行时的正常提示。第二检查 BIOS 虚拟化设置。开机按 F2/F12/Del 进入 BIOS找到Intel Virtualization Technology/AMD SVM Mode确保开启保存退出进入系统后再试。很多品牌机默认关闭这个选项尤其是工作站级别的机器。第三确认没有第三方虚拟机软件和 Hyper-V 冲突。VirtualBox 5.x 老版本和 Hyper-V 同时开会导致启动失败Vagrant 配的 VirtualBox 也常见这个问题。如果你装了 VirtualBox建议升级到 6.x 以上或暂时卸载测试。第四Windows 11 的 VBS基于虚拟化的安全会影响授权。如果系统开了内核隔离内存完整性WSL 2 和 Docker Desktop 的启动速度会变慢甚至报错。可以临时关闭内核隔离测试路径在 Windows 安全中心 设备安全性 内核隔离。5.3 无法枚举容器中的对象访问被拒绝这个报错常在 Docker Desktop 挂载 Windows 目录到容器时出现。典型场景docker run -v C:\project:/app ...然后容器内访问挂载的目录时报无法枚举容器中的对象或者访问被拒绝。根因Windows 文件系统权限和 Docker Desktop 的共享文件驱动gRPC-FUSE之间的权限映射冲突。最常见的是挂载了系统盘根目录或者 Windows 用户目录以外的路径而 Docker Desktop 没有权限读取。排查和解决第一步确认挂载路径在 Docker Desktop 的共享资源范围内。打开 Docker Desktop Settings Resources File Sharing确保你挂载的 Windows 路径在里面。Windows 盘符路径默认差不多都加了但如果你直接挂载C:\这种根目录权限模型很容易崩。第二步改用 Docker 卷或 WSL 路径。如果只是代码目录挂载建议把项目放在 WSL 文件系统里比如~/project然后挂载/home/user/project而不是/mnt/c/Users/...。WSL 路径的 IO 性能远高于/mnt/c路径这也是一个性能优化的关键点后面会细说。第三步如果必须挂载 Windows 目录调整容器内权限docker run -v C:\project:/app --user root ...或者避免使用 Windows 文件系统作为代码挂载盘改成构建镜像时 COPY 进镜像内减少运行时对 Windows 目录的依赖。5.4 error: start the windows daemon from a non-elevated terminal这个报错字面意思从非提升的终端启动 Windows 守护进程。很多人第一次见会懵其实问题不在 Docker Desktop 本身而是 Docker CLI 试图启动 Docker Desktop 时发现没有管理员权限或者 Docker Desktop 根本没有启动。处理方式很直接先启动 Docker Desktop等左上角鲸鱼图标变绿。如果已经在运行检查任务栏右下角图标是否有提示 Docker Engine stopped。然后在 PowerShell普通权限即可执行docker version正常会分别显示 Client 和 Server 的信息。只有 Client 没有 Server说明引擎没起来。这里提一个很容易被忽略的点如果 PowerShell 终端曾经以管理员身份打开过Docker CLI 在某些配置下会误判环境导致和 Docker Desktop 的通信不稳定。简单粗暴的办法是关掉所有管理员终端用普通终端执行命令。这在 Windows 的 UAC 环境下是个经典问题。5.5 端口占用引发的连环问题WSL 里容器端口和 Windows 端口冲突时表现不是 Docker 报错而是容器起来了但服务访问不了或者 Windows 端口被其他进程占住。排查命令如下Windows 侧查端口占用netstat -ano | findstr :3306 tasklist | findstr PIDWSL 侧查端口占用ss -tlnp | grep 3306找到占用进程后要么杀掉要么改容器映射端口。我的建议是本地开发时尽量用非默认端口映射比如 MySQL 映射到3307:3306Redis 映射到6389:6379减少和本机其他服务的冲突概率。初始就规避比事后排查省时间。6. 几个容易被忽略的日常坑资源占用、文件读写、GPU 场景再过一段时间你就会发现Docker 跑起来本身不难了难的是让它一直稳定地跑并且在复杂场景下也能保持良好体验。这一节聊几个我用了大半年 WSL Docker 后觉得最值得写下来的点。6.1 WSL 内存和 CPU 占用过高怎么办前面提过.wslconfig可以限制资源但限制之后还是可能出现占用波动。最常见的原因是 Docker 容器内 JVM、Golang 编译等操作会一下子申请大量内存WSL 2 的机制是用了多少就占多少物理内存。如果发现 WSL 的 vmmem 进程吃掉太多内存先看是哪个容器在搞事docker stats --no-streamdocker stats输出会列出容器的 CPU 百分比和内存占用。找到吃内存最狠的容器后可以在启动时就限制docker run -d --memory1g --cpus1 ...这样容器内进程再怎么膨胀也突破不了 1G 的上限。注意--memory限制对 Java 这类会主动预申请内存的运行时尤其有效否则 JVM 可能按宿主机配置把堆内存初始化得很大白白浪费资源。如果 vmmem 本身占用很高但容器统计不多往往是文件缓存或者其他发行版的进程占用。执行wsl --shutdown强制回收内存或者重启 Docker Desktop 都能缓解。6.2 跨文件系统的 IO 性能差异/mnt/c 慢得像外网WSL 2 里访问 Windows 文件/mnt/c/...和访问 WSL 自身文件/home/...性能差一个数量级。具体的区别WSL 2 自身文件在 ext4 文件系统上跑在虚拟磁盘里而/mnt/c走的是 9P 协议一路经过 Windows 到 Linux 的转换。所以做项目时代码目录的存放位置非常关键。如果你在 Windows 的编辑器比如 VSCode里打开C:\project同时容器挂载的是/mnt/c/project你每次编译、打包都会感受到明显的卡顿。标准解法是开发目录放在 WSL 内部比如~/project用 VSCode 的 WSL 远程模式直接打开 WSL 里的目录容器挂载时用 WSL 路径不用/mnt/c路径这样做之后容器内文件监听webpack、nodemon 这类工具的性能会明显改善IO 瓶颈基本消失。6.3 涉及 GPU 的场景WSL 里的 CUDA 效率虽然不在本文核心范围但wsl安装cuda这个热词搜索量很大值得简单提一嘴。WSL 2 支持 GPU 加速NVIDIA 官方有个 Windows 上的 CUDA on WSL 方案。核心步骤就两步Windows 侧装支持 WSL 的显卡驱动WSL 内装 CUDA Toolkit。然后就能在容器里跑带 CUDA 的工作负载。注意 Docker 容器里跑 GPU 需要额外加参数docker run --gpus all ...不过要提醒的是如果你的主要需求是跑大型机器学习训练WSL 里的 GPU 容器性能上限还是会受桌面系统资源竞争的影响。轻度验证代码、跑跑小模型WSL 完全够用严肃训练还是老实回 Linux 服务器。6.4 在 VSCode 里无缝使用 WSL 和 Docker 的体验最后说一个体验提升很大的操作把开发环境整体搬进 WSL。VSCode 装一个名为WSL的扩展然后远程打开 WSL 里的某个目录这时候 VSCode 的终端、调试器都在 WSL 里运行Docker 命令、文件监听全部原生和直接 ssh 到 Linux 服务器的体验基本一致。再装一个Dev Containers扩展可以直接把 VSCode 附到某个 Docker 容器里在容器里改代码、跑测试Windows 这边只留一个轻量的编辑器外壳。这套组合用下来最大的感受是Windows 只是承载了一个图形环境真正的开发和运行逻辑全部在 Linux 侧这种桌面归桌面开发归开发的剥离感非常舒服。文章写到这里WSL Docker 的组合拳已经讲得比较透了。我实际用的过程中最大的体会是大多数报错都出在环境状态不一致上——WSL 内核版本和 Docker Desktop 版本不匹配、虚拟化开关被主板重置、Windows 更新后组件损坏。遇到问题先别急着重装按文章里的链路一步步排查多数都能在十分钟内定位。如果让我总结一条最实用的建议那就是把.wslconfig、镜像加速、数据盘迁移这三件事在新环境里第一时间做好之后再慢慢按需加东西这套组合长期用下来会稳定得多。