WSL2中安装Docker的完整指南：从环境配置到高效实践-代码聚汇网

WSL2中安装Docker的完整指南：从环境配置到高效实践

芙蓉塘外有轻雷·2026-09-01·阅读 26 GEO检测（免费）

WSL2Docker容器

|难度：普通|阅读约 46 分钟

先讲个我前两天遇到的场景。一个同事想在本机跑个MySQL容器做开发测试，顺手点开了网上的教程，结果卡在Docker Desktop启动上——不是报虚拟化支持未检测到，就是WSL状态异常，前前后后折腾了个把小时。我说你不如直接把Docker装进WSL2里，省掉中间那层Windows图形界面的翻译和调度，他半信半疑试了试，十分钟后容器已经跑起来了。

这类情况我见过太多次。Windows上装Docker，方向其实就两个：要么用Docker Desktop的WSL2后端，要么直接在WSL2的Linux发行版里装原生的Docker Engine。而大多数出问题的人，问题根源恰恰出在第一步——WSL2本身没装好，或者压根没理解这两者之间是什么关系。所以这篇我打算从WSL2和Docker的底层关系讲起，把安装、选型、配置、报错排查一条线串下来，确保你既能照着做，也能理解每一步在干什么。

这篇内容适合：刚接触WSL的Windows用户、在本地搞开发但不想开虚拟机的同学、以及被Docker Desktop各种启动报错折磨过的朋友。核心假设是你对Linux命令有一点基础，但即便完全没有，照着步骤抄也能完成。

1. 为什么是WSL2，而不是虚拟机或Windows原生Docker

1.1 从Docker为什么不能在Windows原生跑说起

很多人第一次接触Docker时会有个困惑：Docker明明是跨平台的，为什么Windows上装起来这么痛？这里得先搞清楚一个基础事实——Docker本身不是虚拟机，它依赖Linux内核提供的namespace、cgroups、overlayfs这些底层机制来实现容器隔离和镜像分层。Windows内核没有这些机制，所以Docker不能在Windows上"原生"运行。

那Windows上到底怎么跑？两条路：

在虚拟机里跑一个完整的Linux系统，然后在Linux系统里跑容器。
用Windows提供的内核级虚拟化平台，由Docker Desktop帮你起一个极简Linux虚拟机，把容器塞进去。

早期Docker Toolbox走的是第一条路，基于VirtualBox，体验很糟糕。后来Docker Desktop基于Hyper-V，依然是个重量级方案，而且和很多VirtualBox、VMware、安卓模拟器的虚拟化方式冲突。直到WSL2出现，Windows上跑Docker这件事才变得体面。

WSL2本质上是一个轻量级虚拟机，但它和传统虚拟机有一个关键区别：它不是完整提供一套硬件抽象，而是通过虚拟化技术直接承载一个真正的Linux内核。也就是说，你在WSL2里运行的不是模拟器，而是一个原生Linux，只是这个Linux生活在Windows的VM里。正因如此，Docker的依赖——namespace、cgroups、overlayfs——WSL2里全都满足。

1.2 WSL2和WSL1的区别，以及和VirtualBox/Hyper-V的对比

很多老教程还在提WSL1。WSL1和WSL2虽然都叫WSL，但架构完全不同：

WSL1是系统调用翻译层，把Linux系统调用翻译成Windows调用，没有真正的Linux内核。对于大多数用户态应用够用，但对Docker这种需要内核特性的软件就是不支持。你在WSL1里尝试装Docker，多半会失败。
WSL2是轻量级虚拟机，跑着货真价实的Linux内核，兼容性接近原生Linux。

所以你在网上看到"The command 'docker-compose' could not be found in this WSL 1 distro"这类报错，多半是发行版还跑在WSL1模式下，解法是把它切到WSL2，后面我会专门讲。

和VirtualBox、Hyper-V这类完整虚拟机相比，WSL2的优势也非常明显：

启动快。WSL2的VM是随用随启的，通常几秒内就能进入一个可用shell。相比之下，完整虚拟机光开机就得几十秒。
资源占用低。WSL2默认动态分配内存和CPU，不用你手动划个固定的4GB内存，宿主Windows内存紧张时会自动回收。
和Windows集成好。这是最让人上瘾的一点。在WSL2里可以直接用explorer.exe .打开Windows资源管理器，Windows的命令行可以无缝调用WSL里的命令，本地开发的时候可以同时在Windows侧用IDE、在Linux侧跑容器。
文件互通。Windows的磁盘会挂载到/mnt/c，WSL2里的文件也能通过\\wsl$\路径从Windows侧直接访问。

1.3 两种最主流的装机路线

明白了WSL2的定位，你就会知道当前主流方案为什么是下面两种：

路线A：Docker Desktop for Windows，开启WSL2后端。Docker引擎实际跑在WSL2里，但Docker Desktop提供Windows图形界面、托盘图标、开机自启、Docker Compose集成，界面友好，是大多数初学者的首选。

路线B：直接在WSL2里装Docker Engine（通常是Ubuntu发行版）。不装Docker Desktop，而是在Linux shell里操作docker命令。这套方案更接近生产环境，适合那些想要纯净、可控、资源占用更低，或者项目本身部署目标就是Linux服务器的人。

我自己的日常主力是路线B，但也不排斥路线A。具体怎么选，我放在第3章详细展开，这里先不纠结。但无论选哪条路线，第一步都一样：把WSL2装好。这是绕不开的地基。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. WSL2安装：第一步就决定成败

2.1 安装前必须确认的三件事

WSL2能不能顺利装，很多时候不是命令敲错，而是环境没准备好。和"virtualization support wasn't detected"这类Docker Desktop报错一样，问题往往出现在虚拟化这一层。所以下面的确认顺序值得认真做一遍。

确认Windows版本。

WSL2要求Windows 10 2004及以上，或者Windows 11。如果你的Windows还停留在旧版本，最好的建议是先更新系统。注意，这里说的Windows 10 2004不是随便看看系统版本号，而是指2020年5月更新那一版及以后的系统。怎么看？Win+R输入winver，弹出的窗口里看版本号。

确认CPU虚拟化已在BIOS开启。

这是最容易被忽略的一步。打开任务管理器 -> 性能 -> CPU，看右下角"虚拟化"是否显示"已启用"。如果显示"已禁用"，需要进BIOS开启Intel VT-x（Intel平台）或AMD-V（AMD平台）。不同主板的BIOS菜单位置不一样，一般在Advanced或Security菜单下找"Intel Virtualization Technology"这类选项。这一步不做，后面整个WSL2、Docker Desktop、安卓模拟器全都会被卡住，而且报错极具迷惑性。

确认Windows功能已启用。

WSL2依赖两个Windows可选功能："适用于Linux的Windows子系统"和"虚拟机平台"。用管理员身份打开PowerShell，执行：

powershell复制dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完重启电脑。如果你用的是Windows 11，这一步大多数情况下系统已经默认开启了，但检查一遍没坏处。

2.2 一条命令装好WSL2，以及"wsl --install太慢"的应对

从较新的Windows 10 2004和Windows 11开始，WSL支持一条命令直接装好：

powershell复制wsl --install

这条命令会自动开启需要的Windows功能、下载WSL组件、安装默认的Ubuntu发行版。装完重启，设置一个Linux用户名和密码就进入了Ubuntu环境。

但很多人卡在了这里——"wsl --install太慢"。这个慢通常体现在两个环节：

第一，WSL组件下载慢。这时候可以考虑使用--web-download参数，让安装过程直接从网络下载最新的WSL版本，而不是走Windows Update的分发通道：

powershell复制wsl --install --web-download

在部分网络环境下，这个参数反而更快，因为它能利用更直接的下载通道。热词里那个wsl --install --distribution ubuntu-24.04 --web-download就是同样的逻辑，指定发型版加web下载。

第二，发行版下载慢。wsl --install默认会下载一个Ubuntu发行版，这个下载体积往往有好几百MB，初次安装时等两分钟以上很正常。如果确实慢得离谱，考虑手动下载发行版安装包（.appx或.msixbundle），然后用Add-AppxPackage安装，或者用wsl --import导入已有的rootfs。

判断到底卡在哪个环节，有个实用技巧。执行wsl --install后，如果长时间停在某个百分比，可以开个浏览器去Microsoft Store搜一下Ubuntu，看能不能加载出页面。如果Store也卡，大概率就是下载通道本身的问题。

2.3 老版本Windows和老机型的兜底方案

如果你的Windows版本比较老，或者系统更新被限制，没法用wsl --install，还有一条手动路线：

先启用"适用于Linux的Windows子系统"和"虚拟机平台"两个功能，命令见2.1，然后重启。
下载并安装WSL2内核更新包。微软官方提供wsl_update_x64.msi，安装即可。
将WSL默认版本设为2：管理员PowerShell执行wsl --set-default-version 2。
在Microsoft Store里搜索并安装你喜欢的发行版（Ubuntu、Debian、Kali等都行）。Store打不开的话，可以下载发行版的.appx离线包手动安装。

这个兜底方案虽然步骤多点，但每一步都是可独立验证的，出错也更容易定位。

2.4 验证WSL2真的装好了

装好之后，无论如何都要做一遍验证，避免后面Docker出问题时才回过头来怀疑WSL没装好。

powershell复制wsl --list --verbose

正常输出会列出已安装的发行版和版本信息，State是Running或Stopped，VERSION是2。如果看到VERSION是1，说明发行版还跑在WSL1上，需要手动转换：

powershell复制wsl --set-version Ubuntu 2

注意把Ubuntu替换成你实际安装的发行版名称。这个转换过程需要几分钟，耐心等它跑完。另外再确认一下默认登录用户——这是个小细节，很多人在安装发行版时设置的默认用户不是root，后面在WSL里执行docker命令时总会遇到权限问题，反而以为是Docker没装对。

3. Docker Desktop还是原生Docker Engine：两种路线怎么选

3.1 Docker Desktop for Windows（WSL2后端）

Docker Desktop from Windows是Docker官方提供的桌面产品，安装时会检测你机器上的WSL2，并默认将Docker Engine跑在WSL2里。这玩意最大的好处是省心：

装上就有图形界面，能直观看到正在运行的容器、镜像、卷。
自带Docker Compose。
开机自启，托盘图标一键启停。
可以在Docker Desktop里设置WSL2集成的发行版，让WSL里和Windows侧共享同一个Docker上下文。

但它的缺点也明显。一是商业授权问题——对大型企业（超过250人或者年收入超过1000万美元）使用Docker Desktop是收费的，这一点很多公司有硬性合规要求。二是它本质上在WSL2之上又跑了一套Docker管理进程，资源开销偏高，镜像多了之后磁盘占用也很可观。三是启动流程多了Windows图形层和WSL后端两层，任何一个环节异常就可能报错，就是那些"virtualisation support wasn't detected"、"we've detected that you have an incompatible version of windows"之类。

3.2 WSL里直接装Docker Engine

路线B是在WSL2里装原生的Docker Engine。装完之后的体验什么样呢？就是你在WSL的shell里敲docker命令，和在一台Linux服务器上敲没有区别。没有图形界面、没有托盘、没有右击菜单，但换来的是纯净和控制力。

优势：

更接近生产环境。你本地怎么敲命令，部署到服务器上就怎么敲。
资源开销低。没有Windows侧Docker管理进程，WSL里只跑着一个dockerd守护进程。
没有授权合规问题，Docker Engine本身的许可证对个人和小团队友好。
可控性极强。所有配置都是Linux侧的配置文件，跟服务器完全一致。

劣势：

没有图形界面，新手会不习惯。
需要自己处理开机自启问题。
Docker Compose需要单独安装（虽然一般也就一条命令）。
和Windows侧的集成弱一些，某些操作（比如右键菜单）不存在。

3.3 对比与我的选择建议

画个直观的对比表：

维度	Docker Desktop（WSL2后端）	WSL2原生Docker Engine
安装难度	较低，图形安装向导	中等，几条命令
图形界面	有	无
资源占用	偏高	低
启动方式	Windows开机自启，托盘管理	依赖WSL里的systemd或手动启动
Docker Compose	内置	需单独安装
生产环境一致性	一般	高
大企业授权	收费	无此问题
适合人群	初学者、重GUI操作	开发者、部署人员、运维

我在不同场景下两种都用。如果只是临时在Windows上跑个中间件做测试，比如要个MySQL、Redis，装个Docker Desktop确实省心；如果是正经开发，项目最终要部署到Linux服务器，那我强烈建议直接在WSL2里装原生Docker Engine。原因很简单——你本地敲的docker build、docker-compose、docker run命令，在生产环境一字不差地又敲一遍，遇到任何问题都有一致性可以回溯。而Docker Desktop的图形界面虽然方便，反而容易让人忽略了命令行本身。

4. 在Ubuntu中安装原生Docker Engine的完整步骤

4.1 进入WSL并准备环境

假设你已经装好了Ubuntu发行版并进入WSL，先用uname -a确认内核版本。Docker要求WSL2的内核版本不能太老，如果太旧可以跑wsl --update更新WSL组件。

进入WSL后，第一步永远是更新软件包索引：

bash复制sudo apt update

然后安装安装Docker需要的依赖包：

bash复制sudo apt install -y ca-certificates curl

这里多说一句，ca-certificates和curl是Docker官方安装文档要求的基础依赖，前者用于校验HTTPS证书，后者用于下载Docker仓库的GPG密钥。少装任何一个都可能在下文的关键步骤报错。

4.2 添加Docker官方仓库

Docker官方推荐通过仓库安装，而不是直接下载deb包，因为这样后续apt upgrade时能自动更新Docker。官方安装文档里的命令每年都会微调，当前的主流流程如下：

bash复制# 创建存放GPG密钥的目录
sudo install -m 0755 -d /etc/apt/keyrings

# 下载Docker官方GPG密钥
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# 设置密钥权限
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# 添加Docker仓库
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

如果你用的是Ubuntu 22.04，$VERSION_CODENAME会是jammy，这个变量自动替你填好了。注意如果你用非LTS版本或者更特殊的状态，可能需要手动指定codename，不过WSL里一般都用LTS版本，这个默认流程足够。

然后更新索引并安装Docker Engine、CLI和containerd：

bash复制sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

docker-compose-plugin是Docker Compose的现代版本，安装后能直接使用docker compose子命令，不需要单独装老版本的docker-compose。

4.3 安装与验证

安装完成后，先验证守护进程状态：

bash复制sudo service docker status

如果没启动则手动启动：

bash复制sudo service docker start

然后跑一个最简单的容器验证：

bash复制sudo docker run hello-world

如果输出一长段"Hello from Docker!"说明安装成功。注意，为了验证Docker真正可用，建议再跑一个稍微实际点的容器，比如：

bash复制sudo docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql:8.0

然后查端口：

bash复制sudo docker ps

这样能确认端口映射没问题。MySQL 8.0的镜像有几个GB，初次拉取会比较慢，正好引出了第5章的镜像加速问题。

4.4 免sudo使用docker

刚装完Docker后操作都要带sudo，这是因为docker CLI默认通过/var/run/docker.sock与守护进程通信，而这个socket由root所有。每次敲命令都加sudo很烦，官方给出的方法是把当前用户加入docker组：

bash复制sudo usermod -aG docker $USER

然后退出WSL再重新进入（或者执行newgrp docker），验证一下：

bash复制docker ps

能正常输出列表就没问题了。这里有个坑：如果你的默认登录用户是root，那不存在权限问题；但如果你用自己的用户名登录，这个步骤就很有必要。另外，加入docker组后一定要重新登录一次才会生效。

4.5 让docker在WSL启动后自动运行

直接装在WSL2里的Docker Engine，在WSL重开后需要手动启动守护进程，这一点是最让从Docker Desktop切过来的人不习惯的。解决方式有几种。

较新的WSL2发行版默认启用了systemd，在Ubuntu 22.04及以后的WSL里，可以确认：

bash复制systemctl --version

如果systemd可用，直接启用Docker服务：

bash复制sudo systemctl enable docker
sudo systemctl start docker

启用后每次WSL启动时Docker会自动运行。如果你的发行版还没启用systemd（较老的Ubuntu版本），需要编辑/etc/wsl.conf：

bash复制sudo nano /etc/wsl.conf

写入：

ini复制[boot]
systemd=true

然后在Windows侧执行wsl --shutdown，重新打开WSL。之后再执行systemctl enable docker即可。这一步做完，你基本上就拥有了一套和Linux服务器行为一致、开机即用的Docker环境。

5. 镜像加速、网络互通与文件性能：WSL2里用Docker的进阶配置

5.1 docker pull慢？先配置镜像加速器

第一次在WSL里拉镜像，很多人都会对着进度条怀疑人生。docker.io的官方仓库在部分网络条件下确实慢，一个几百MB的基础镜像能拉十分钟以上。解法是配置镜像加速器。

镜像加速器的原理是Docker官方提供的registry mirror机制。你可以在/etc/docker/daemon.json里配置一个或几个镜像源，Docker拉取镜像时会先从这些镜像源请求，拉不到再回源到Docker Hub。

bash复制sudo mkdir -p /etc/docker
sudo nano /etc/docker/daemon.json

填入：

json复制{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://dockerproxy.com",
    "https://docker.nju.edu.cn"
  ]
}

注意，这里列出的镜像源地址可能会随时间失效，好的做法是搜索当前可用的公共docker registry mirror，或者配置自己云服务商的加速器地址。改完配置后重启Docker：

bash复制sudo systemctl restart docker

然后重新docker pull，速度差异会非常直观。

另外一个小技巧：docker pull时指定具体的镜像标签会减少元数据查询时间，比如mysql:8.0而不是mysql，后者每次都要额外解析latest标签。

5.2 Windows与WSL2网络的互通与端口访问

WSL2服务端口的访问方式在较新的Windows版本上变得非常简单。WSL2虽然运行在虚拟网络里，但Windows侧在默认配置下会把WSL2的端口转发到localhost。也就是说，你在WSL2里启动了一个监听3306的MySQL容器，浏览器或数据库客户端直接连localhost:3306就能访问，不需要关心WSL2的虚拟IP是多少。

反过来也一样，在WSL2里访问Windows侧的服务，直接用localhost就行。比如你在Windows上跑了某个web服务在8080端口，WSL里执行curl localhost:8080可以访问到。

但有一个容易踩坑的场景：多物理机访问。如果你的同事想通过你机器IP访问WSL里跑着的服务，默认是访问不到的，因为WSL2的端口转发是本地回环级别的。此时要么通过Windows侧做端口转发加入防火墙规则，要么借助其他工具做内网穿透，这个就要看具体网络环境了。

更深一层的网络问题：WSL2每次启动时虚拟网卡IP可能会变，依赖固定IP的脚本要注意这点。如果你的场景是需要WSL2固定IP的（比如局域网设备要持续访问），可以考虑配置WSL的NAT模式替代方案或镜像网络模式，但配置复杂度会上升，普通开发场景一般用不到。

5.3 文件挂载的"慢"不是玄学

在WSL2里跑Docker时，最影响使用体验的性能瓶颈往往来自文件挂载。具体来说，把Windows文件系统（/mnt/c下的路径）直接挂载为容器的数据卷，读写性能会明显低于Linux文件系统。

这是因为WSL2的/mnt/c路径底层走的是9P协议，它本身就是为了兼容性实现的，不是为本机高性能读写设计的。如果你有大量文件读写需求，比如编译、数据库存储，把数据放在WSL2自己的Linux文件系统里（比如/home/用户名/data），速度会快得多。

实际操作建议：

代码仓库放在WSL2侧：~/projects
Windows侧的IDE如果需要打开这个目录，用\\wsl$\Ubuntu\home\用户名\projects
Docker的数据卷目录放在Linux侧，不要放在/mnt/c下
如果必须挂载Windows目录，接受性能损耗，或者考虑使用//wsl$/反向挂载的替代方案

5.4 GPU透传（CUDA）与nvml报错

热词里有个非常典型的报错："failed to initialize nvml: gpu access blocked by the operating system"。这通常发生在WSL2里做CUDA相关开发，或者跑需要GPU的Docker容器（比如AI模型推理）时。

WSL2本身支持GPU加速，前提是：

Windows侧安装了支持WSL的NVIDIA显卡驱动。这个驱动不是普通的Windows驱动，而是NVIDIA专门提供的WSL版驱动，确保Windows和WSL2里都能访问GPU。
WSL里安装了NVIDIA Container Toolkit，它是让Docker容器能访问GPU的中间层。

安装NVIDIA Container Toolkit：

bash复制curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

然后在容器里用--gpus all参数：

bash复制docker run --rm --gpus all nvidia/cuda:11.8-base nvidia-smi

能正常输出GPU信息就说明透传成功。如果出现"gpu access blocked by the operating system"，排查重点就是WSL驱动是否正确安装，以及Windows侧驱动是否更新到了支持WSL的版本。这个报错的意思就是操作系统禁止了GPU访问，不是NVIDIA Container Toolkit的问题。

6. 高频报错排查：这些坑我基本都踩过

6.1 wsl -d ubuntu-22.04 系统找不到指定的文件

这个报错我在技术交流群里见过非常多。执行wsl -d ubuntu-22.04提示"系统找不到指定的文件"，原因通常是这么几个：

发行版名称不对。你初始安装时可能不是Ubuntu-22.04，而是Ubuntu-24.04或者Ubuntu。先用wsl --list --verbose看实际安装的发行版名称，注意大小写和空格必须完全一致。
发行版已注册但内核失效。如果你之前做过wsl --unregister操作，或者Windows更新后WSL组件损坏，可能会出现这个问题。解法是注销后再重新安装发行版，或者用wsl --install --distribution Ubuntu-22.04重新装一次。
默认发行版没设置。如果你装了多个发行版且没设默认，有些老版本命令会报错。用wsl --set-default Ubuntu-22.04设置一次默认发行版。
更隐蔽的情况：WSL服务没启动。Windows的服务列表里，适用于Linux的Windows子系统服务可能被禁用。手动启动它或者彻底重启电脑一般能解决。

排查思路：先跑wsl --list --verbose确认发行版存在，再跑wsl -d 完全匹配的发行版名。如果都正常，就看服务状态和WSL版本。

6.2 docker-compose could not be found in this WSL 1 distro

这个报错直接把问题暴露了：你的发行版还跑在WSL1上。Docker Compose没法在WSL1里工作，因为它依赖Docker Engine，而WSL1不支持原生Docker。

处理方法明确：

powershell复制wsl --set-version <发行版名> 2

在WSL中确认一下：

bash复制docker info | grep -i kernel

如果能看到Linux内核相关信息，说明你已经跑在WSL2上了。这类问题本质上是WSL版本没有转换干净。Windows更新有时会把WSL2的配置重置，所以要格外注意wsl --list --verbose里显示的版本号。

6.3 Docker Desktop 报未检测到虚拟化支持

"Docker Desktop failed to start because virtualisation support wasn't detected"是又一个高频报错，而且它的误导性极强。大部分情况下，你的CPU是支持虚拟化的，只是没开启，或者被其他软件占用了。

排查顺序：

打开任务管理器 -> 性能 -> CPU，看虚拟化是否显示"已启用"。
如果显示"已禁用"，进BIOS开启Intel VT-x或AMD-V。
如果显示"已启用"，但Docker Desktop依然报错，检查是否同时安装了多个虚拟机平台。某些版本的VirtualBox、VMware或旧版Windows Hyper-V会与Docker Desktop冲突。
如果以上都排除了，检查Windows版本。旧版本Windows对WSL2支持不完整，会触发这个报错。

另外有个WSL特有的坑：如果你刚装完WSL2但是之后没有重启过Windows，Docker Desktop的检测机制可能无法正确识别虚拟化状态。重启大法在这种时候依然有效。

6.4 wsl --update 时服务无法启动

热词里有一条非常具体的报错："wsl --update 正在安装: 适用于 linux 的 windows 子系统无法启动服务，原因可能是已被禁用或与其相关联的设备没有启动。"

这个报错的核心是Windows服务"适用于Linux的Windows子系统"（服务名通常是LxssManager）没有正常启动。可以在管理员PowerShell里执行：

powershell复制Get-Service LxssManager
Stop-Service LxssManager
Start-Service LxssManager

如果服务被禁用，把启动类型设为自动：

powershell复制Set-Service LxssManager -StartupType Automatic
Start-Service LxssManager

如果还是启动不了，检查依赖服务，比如"虚拟机平台"相关的服务是否被禁用。大多数情况下，把BIOS虚拟化打开、Windows功能里"虚拟机平台"勾上、服务设为自动，这条链就通了。

我在实际处理过程中发现一个经验：wsl更新失败后，最稳妥的做法是以管理员身份完全重启WSL，顺序是wsl --shutdown，然后重启LxssManager服务，再wsl --version看版本号。很多一次性的更新失败，重启服务后就自愈了。

关于WSL和Docker的安装与配置，最后再分享一点我个人的使用体会。我在WSL2里装Docker Engine已经用了很长一段时间，从Ubuntu 20.04一路用到24.04，中间踩过不少坑，但整体稳定性和生产环境的一致性确实让人安心。如果你是被Docker Desktop折腾烦了才来看这篇文章，不妨给WSL2里的原生Docker Engine一个机会；如果你是完全的新手，先装Docker Desktop跑通流程也完全不丢人。无论是哪条路，最核心的那块拼图永远是WSL2本身——系统版本对齐、虚拟化打开、WSL版本确认，三件事到位了，后面的Docker安装基本就是复制粘贴的事。