Windows上跑Docker：WSL2部署全流程与高频避坑指南-代码聚汇网

Windows上跑Docker：WSL2部署全流程与高频避坑指南

是个少女·2026-09-25·阅读 25 GEO检测（免费）

WSL2Docker DesktopWindows容器

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

Windows上装Docker，看着是个特别常规的操作，但真正动手你会发现坑比想象中多。尤其是最近大家喜欢在本地跑大模型、装MySQL、Redis、Elasticsearch这类服务，Windows + WSL2 + Docker这套组合几乎成了标准答案。我自己的主力开发机就是Windows，这些年折腾过Hyper-V后端、纯虚拟机方案，最后长期稳定在Docker Desktop + WSL2这个模式下。这篇就把完整的部署过程、底层原理、以及我踩过的坑一次性说清楚，适合想在本机搭建容器环境、跑数据库或大模型实验的人参考。

1. 为什么Windows上跑Docker，大家最后都选了WSL2

1.1 Windows下的容器方案，我踩过的三条路

先说结论：Docker在Windows上并不是原生应用，因为容器技术依赖Linux内核特性。Windows想要跑Linux容器，必须有一个“能提供Linux内核环境”的底层。目前主流的路线有三条，我逐一试过：

Docker Desktop + Hyper-V后端：这是早期方案，依赖Windows自带的Hyper-V虚拟机监控程序。问题很明显，Hyper-V会占用大量系统资源，启动速度慢，而且对Windows版本有要求，家庭版默认没有Hyper-V。
独立Linux虚拟机 + Docker Engine：比如用VirtualBox或VMware装一个Ubuntu，然后在虚拟机里装Docker。这个方案最稳，但资源浪费大，每次启动虚拟机都要等，和Windows的文件共享、网络互通也比较麻烦。
Docker Desktop + WSL2后端：这是Docker官方现在默认推荐的路线。WSL2本质上是一个轻量级虚拟机，但它由Windows直接管理，启动只要几秒，内存占用比完整虚拟机低得多。Docker Desktop把容器引擎直接跑在WSL2的发行版里，Windows这边只留一个命令行客户端和图形界面。

我最后长期用的是第三种。核心原因有四个：第一是启动速度快，Windows开机后WSL2默认就在后台待命，Docker Desktop打开后几乎秒连；第二是资源开销小，WSL2的内存是动态分配的，不用给整个虚拟机预留固定大小；第三是文件互通方便，Windows可以直接访问WSL2里面的文件路径，WSL2也能访问Windows磁盘；第四是Docker官方明确支持，新版本基本不需要额外折腾。

注意：如果你机器上开启了Hyper-V，或者手动启用了“基于虚拟化的安全性”（VBS），Docker Desktop的WSL2后端偶尔会报一些奇怪的错误。后面我会专门讲排查方法。

1.2 WSL2到底是什么，它给Docker提供了什么

搞清楚WSL2的定位，能帮你省掉后续很多排查时间。WSL2和第一代WSL完全不同，WSL1是Windows内核里实现的一套Linux系统调用翻译层，兼容性有限；而WSL2是一个真正的轻量级虚拟机，运行着一个完整的Linux内核，只不过Windows把这个虚拟机的启动、休眠、资源调度全都接管了。

Docker Desktop的WSL2后端工作方式是这样的：WSL2里面运行着一个完整的Linux发行版，Docker的守护进程（dockerd）就跑在这个发行版内部。你在Windows命令行里敲docker命令时，Windows侧的Docker CLI通过本地的gRPC接口，把指令转发给WSL2里的守护进程，由它去创建和管理容器。你看到的docker ps、docker run，底层实际都是在WSL2的Linux环境里执行的。

用生活里的事情来类比：Windows是驾驶室，WSL2是后备厢里的微型发电机，Docker就是装满工具的箱子。驾驶室里你只管操作，真正干活的地方在发电机上。

明白了这一点，很多问题就能理解了。比如容器里的网络端口为什么会直接出现在Windows上？因为WSL2和Windows共享网络栈，WSL2内监听端口的进程，从Windows这边直接用localhost就能访问。再比如为什么容器数据在Windows磁盘上访问很慢？因为容器跑在WSL2的ext4文件系统里，跨系统访问Windows的NTFS分区需要额外转换，这个开销是物理级别的，不是软件能绕过的。

1.3 这套方案的适用边界

WSL2 + Docker这套方案，最适合的场景是本地开发、实验验证、临时服务部署。我平时用它跑MySQL、Redis、Nginx，也用它做大数据组件的单机实验，比如Doris、Elasticsearch，还有最近比较火的Ollama本地大模型，这套环境都能很好地承接。

但它也有明确的边界。首先是不要当成生产环境，WSL2的资源调度、系统服务、开机自启机制都不是为7x24小时服务设计的，生产环境还是老老实实用Linux服务器。其次是不适合跑Windows容器，Docker虽然支持Windows容器模式，但生态完全不同，如果你要跑的是.NET Framework这类Windows专属容器，WSL2路线帮不上忙，得切换Docker Desktop的容器模式。第三是GPU透传，虽然WSL2已经支持NVIDIA GPU直通，但配置过程比Windows原生稍微复杂，遇到驱动版本问题也会多一些。

我给你的建议是：先想清楚自己要在Windows上跑什么。如果只是跑Linux容器、做本地测试、实验大数据组件，WSL2方案闭眼选。如果对性能敏感，尤其是数据库IO密集场景，建议把数据目录放在WSL2内部文件系统，别放在/mnt/c下，这个细节后面会细说。

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

2. 动手之前，先把环境底盘检查明白

2.1 硬件虚拟化检查：为什么装机时最容易卡在这一步

部署WSL2和Docker之前，最容易被忽略但又最关键的一步，是确认CPU虚拟化已经开启。WSL2是虚拟机，虚拟化技术必须可用，否则启动就报错。常见报错就是Docker Desktop启动失败，提示虚拟化支持未检测到。我遇到很多次，原因翻来覆去就那么几个。

先教你快速检查CPU虚拟化是否启用。打开任务管理器，切到“性能”选项卡，点CPU，看右下角“虚拟化”这一项。如果显示“已启用”，说明CPU虚拟化没问题；如果显示“已禁用”，就需要进BIOS开启。不同主板的BIOS界面不一样，但选项一般叫“Intel Virtualization Technology”或“VT-x”，AMD平台叫“SVM Mode”或“AMD-V”。开机按Del或F2进BIOS，找到这个选项启用，保存重启就行。

还有一个很隐蔽的坑是“基于虚拟化的安全性”（VBS）和“内存完整性”功能。Windows 11默认开启VBS，它会占用虚拟化资源，有时会让Docker Desktop的WSL2后端冲突。如果你确认CPU虚拟化已开启、BIOS没问题、WSL2也装上了，但Docker还是起不来，可以在“Windows安全中心 - 设备安全性 - 内核隔离”里暂时关掉“内存完整性”，重启再试。这个方法我实测很多次，能解决相当一部分玄学问题。

另外提醒一句：如果你之前为了某些实验手动启用了Windows的Hyper-V，建议先确认它和Docker Desktop能否共存。现代版本的Docker Desktop一般可以共存，但老版本容易冲突。能不用Hyper-V就不用，保持WSL2方案的纯粹性，排查起来最省心。

2.2 Windows版本和系统更新：有些错不是你操作的问题

WSL2和Docker Desktop对Windows版本有明确要求。WSL2需要Windows 10 2004及以上版本（build 19041以上），Windows 11则全部支持。Docker Desktop目前要求64位Windows 10 22H2以上或Windows 11。如果你用的是Windows Server 2019/2022，也能装，但步骤略有不同，需要手动开启更多功能。

版本过老时，常见的现象是执行wsl --install命令直接提示不支持，或者Docker Desktop装好后提示WSL版本太旧，无法启动。这个错不是你操作的问题，是系统底子不够新。解决思路只有一个：把系统更新推到位。

我建议在动手前先执行一次完整的Windows Update，把系统补丁装完。WSL2的底层驱动、内核更新，有时候就藏在系统更新里。你Windows更新装不全，后面wsl --update也容易失败，Docker Desktop也会出现各种莫名奇妙的启动问题。

提示：打开“设置 - Windows更新”，点“检查更新”时，不光要看“质量更新”，还要看看“可选更新”里有没有“Windows Subsystem for Linux”相关的更新项。把这个也装上，能省去后面很多麻烦。

2.3 网络和下载慢的预案：先准备好再动手

部署过程中，下载WSL发行版和Docker镜像是最费时间的环节。国内网络环境下，wsl install和镜像拉取经常卡在进度条上。不是你的操作不对，是网络问题。

先说WSL安装慢。wsl --install -d Ubuntu时候，下载源用的是微软官方服务器，国内速度不稳定。慢到无法忍受时，有两个替代方案。第一个方案是先去微软官网手动下载“适用于 x64 计算机的 WSL2 Linux 内核更新包”，安装完再执行wsl --set-default-version 2。第二个方案是换用阿里云或清华的WSL镜像源，手动下载发行版rootfs包，用wsl --import导入。这个方案更适合有经验的用户，新手建议优先用离线内核包+换流程的方式。

再说Docker镜像慢。Docker Hub在国内访问很不稳定，拉镜像经常超时。解决办法是给Docker Desktop配置Registry Mirror，也就是镜像加速器。这个配置后面会详细讲，这里先提醒你提前准备好。配置好加速器后，docker pull mysql、docker pull redis这种常见镜像，速度会有明显提升。

3. 从零到能跑容器的完整流程

3.1 开启系统功能：两条命令讲清楚

部署第一步，是启用WSL相关的Windows功能。必须以管理员身份打开PowerShell，右键开始菜单就能找到“终端(管理员)”或“Windows PowerShell(管理员)”。

需要执行两条命令：

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

第一条命令启用的是“适用于Linux的Windows子系统”，这是WSL的基础组件。第二条命令启用的是“虚拟机平台”，WSL2要跑完整内核，必须依赖这个虚拟化平台组件。两条命令执行完，系统会提示重启，照做就行。

为什么不是一条命令搞定？因为这两个功能是独立的。WSL1只需要子系统功能，WSL2还需要虚拟机平台。Docker Desktop的WSL2后端必须要WSL2，所以两条都得开。如果你只开第一条，WSL2会一直停留在1.x版本，Docker Desktop也用不了。

有些教程会让你去“启用或关闭Windows功能”界面手动勾选，效果一样，但命令行更省事，而且可以一条条看到状态反馈。我推荐用命令行。

3.2 安装WSL2并设置默认版本

系统重启后，继续在管理员PowerShell里操作。先用下面的命令把WSL更新到最新版，并确保默认版本是WSL2：

bat复制wsl --update
wsl --set-default-version 2

wsl --update会下载最新的WSL内核，这个命令在新版Windows上自带。如果提示找不到wsl命令，说明你的Windows版本太旧，先完成系统更新，或者去微软官网手动下载WSL安装包。如果wsl --update卡住不动，多半是网络问题，可以稍后重试，或者用离线内核安装包。

然后安装一个发行版。我常用的是Ubuntu 22.04 LTS，稳定、生态好、Docker支持最省心。执行：

bat复制wsl --install -d Ubuntu-22.04

安装过程会要求设置Linux用户名和密码。这个用户是你后续在WSL2里操作时用的身份，密码可以直接密码框无回显输入，别按键盘没反应就以为坏了。

装完以后用下面的命令确认状态：

bat复制wsl -l -v

如果看到Ubuntu那一行“VERSION”列显示“2”，说明WSL2模式生效了。如果显示“1”，执行一次wsl --set-version Ubuntu-22.04 2，把它切换到WSL2。

3.3 安装Docker Desktop并切换到WSL2后端

WSL2环境就绪后，去Docker官网下载Docker Desktop for Windows，下载慢的话可以用一些国内镜像站加速下载，但要注意核对安装包哈希值。双击安装，在安装选项里务必勾选“Use WSL 2 based engine”。这一步是整套方案的核心，如果没勾，Docker Desktop会用Hyper-V后端，后续体验完全不同。

安装完成第一次启动时，Docker Desktop会弹出对话框，询问是否将Docker和WSL2集成。此时在Settings的“Resources - WSL Integration”里，确认你安装的Ubuntu发行版在启用列表里。开启后，你在Windows命令行里敲docker命令，实际就是和这个发行版里的Docker引擎通信。

装好后验证一下：

bat复制docker --version
docker info

docker info输出里如果能看到“Operating System: Ubuntu”之类的Linux信息，说明Docker引擎确实跑在WSL2的Linux环境里，而不是Windows原生。看到这个，部署就算成功一大半了。

提示：有时候docker命令执行后提示“cannot connect to the Docker daemon”，大多数情况是Docker Desktop还没完全启动。等桌面端图标变成稳定的鲸鱼图标，再执行docker命令就好。也可以在托盘图标右键选择“Restart”，多试几次。

4. 部署完成后的第一轮验证和配置

4.1 快速验证守护进程正常

Docker Desktop装好后，先跑一个最小的容器验证整体链路：

bat复制docker run hello-world

这个镜像只有几KB，主要用来验证Docker引擎能否正常拉取镜像、创建容器并执行。如果你看到类似“Hello from Docker!”的输出，说明从Windows CLI到WSL2守护进程的整条链路是通的。如果你之前配过镜像加速器，这个命令的执行速度也顺便测试了加速效果。

如果docker run卡在“Unable to find image 'hello-world:latest' locally”后超时，先检查镜像加速器配置，再检查网络。如果提示“error during connect”，多半是WSL2发行版没启动，执行wsl --shutdown再重新打开Docker Desktop。

这条验证链路是我的习惯动作，换新电脑、重装系统后第一件事就是跑它。通不过就先别往下折腾，先把基础链路搞定。

4.2 配置镜像加速器：为什么需要，怎么配

Docker Hub的仓库地址在国外，国内拉大镜像经常慢到怀疑人生。配置国内镜像加速器是部署后最值得做的一件事。

打开Docker Desktop，进入Settings - Docker Engine，在JSON配置里加一行：

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

不同加速器服务商可能有变化，建议自行搜索当前可用的国内镜像源，配置后点击“Apply & Restart”。

配完之后可以用docker info看Registry Mirrors字段是否生效。我实测下来，配置加速器后拉取MySQL、Redis、Ubuntu这类常用基础镜像，速度快了好几倍。但要注意，加速器主要加速的是Docker Hub官方镜像，一些第三方仓库的镜像还是需要走原始地址，速度不稳定是正常的。

4.3 用.wslconfig管住vmmem内存大户

WSL2跑起来后，很多Windows用户会发现任务管理器里多了一个“vmmem”进程，内存占用动不动几个GB。这个进程就是WSL2虚拟机的内存，Docker容器、WSL发行版都算在它头上。

默认情况下WSL2会用到Windows总内存的50%，如果你机器内存不大，很快会吃紧。解决办法是在用户目录下创建.wslconfig文件，显式限制资源。文件路径是C:\Users\你的用户名.wslconfig。

ini复制[wsl2]
memory=4GB
processors=4
swap=2GB
localhostForwarding=true

保存后执行wsl --shutdown，再重新打开WSL2，配置就生效了。memory字段控制虚拟机最大内存，processors字段控制CPU核数，swap是交换空间，localhostForwarding保持默认true就可以。

这个配置我给很多朋友推荐过。特别是本地同时跑Docker和开发服务的人，限制一下WSL2内存，Windows流畅度会明显改善。注意别把memory设置得太小，比如低于2GB，否则容器内存不足会直接OOM。

4.4 文件系统与数据存储的位置选择

WSL2的文件系统有自己的一套逻辑，理解它就能少踩很多坑。WSL2发行版内部是ext4文件系统，Windows盘符默认挂载在/mnt/c、/mnt/d这些路径下。

如果容器需要挂载数据目录，强烈建议把宿主机目录放在WSL2内部的Linux路径下，比如/home/你的用户名/data，而不是放在/mnt/c/Users/xxx。原因很简单：WSL2访问/mnt/c是跨文件系统IO，性能损耗巨大，尤其是数据库这种频繁读写磁盘的应用，差距可能几倍甚至十几倍。

我自己跑MySQL时，数据目录放在/home/xxx/mysql-data，速度快且稳定。Windows这边想访问Linux里的文件，直接在文件资源管理器地址栏输入\wsl$\Ubuntu-22.04，就能看到整个文件系统，复制文件也很方便。

注意：不要为了图省事，把容器数据目录直接挂到Windows的D盘。实测MySQL在/mnt/d下性能明显下降，还会出现文件锁异常的问题。数据目录老老实实放WSL2内部，需要备份时再拷回Windows。

5. 实战：用这套环境把常用服务一个个跑起来

5.1 MySQL 8.0：命名卷和初始密码那些事

环境就绪后，从最常用的MySQL开始。Windows和WSL2之间端口本来就是互通的，容器里监听3306端口，Windows直接就能用localhost访问。

跑MySQL 8.0容器，推荐用这条命令：

bash复制docker run -d \
  --name mysql8 \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=yourpassword \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

这里几个参数别随意省略。MYSQL_ROOT_PASSWORD是初始化root密码，第一次启动必须给，否则容器起不来。mysql-data是一个命名卷，MySQL的数据文件持久化在里面，容器删了重建数据还在。如果不指定-v，容器一点删，数据全没。

启动后验证一下：

bash复制docker ps
docker exec -it mysql8 mysql -uroot -p

在WSL2里也可以直接用mysql命令行连，但在Windows里更方便的方式是用Navicat、DBeaver这类图形工具，连接地址填localhost，端口3306，用户名root，密码就是刚才设置的。

踩过的坑提醒一句：如果你改过MySQL容器端口映射，比如改成3307，连接串里的端口号就必须改。另外MySQL服务启动需要几秒，docker run之后立刻连接可能会报连接失败，等五秒再试。

5.2 Redis主从：一条docker compose搞定

MySQL是单机场景，Redis主从则适合演示docker compose的编排能力。在WSL2的Linux环境里建一个目录，比如/home/xxx/redis-cluster，然后创建docker-compose.yml：

yaml复制version: "3.8"
services:
  redis-master:
    image: redis:7.0
    container_name: redis-master
    ports:
      - "6379:6379"
    command: redis-server --appendonly yes --requirepass redispass

  redis-slave:
    image: redis:7.0
    container_name: redis-slave
    depends_on:
      - redis-master
    ports:
      - "6380:6379"
    command: redis-server --slaveof redis-master 6379 --masterauth redispass

在命令行执行：

bash复制docker compose up -d

两个容器自动创建，主从关系建立。用redis-cli连接验证一下：

bash复制docker exec -it redis-master redis-cli -p 6379 -a redispass info replication

看到role:master和connected_slaves:1，说明主从配置成功。Redis主从这个案例，特别适合用来理解docker compose的依赖管理和服务编排，比手动run两个容器再折腾网络配置省心很多。

如果你需要更大的实验规模，比如三主三从集群，同样可以在compose文件里扩展，但要注意Cluster模式需要额外配置，这里不展开。

5.3 本地大模型：容器里跑Ollama和DeepSeek

最近大家特别关心在本地部署大模型，Windows上这套WSL2 + Docker环境正好能派上用场。最省力的方案是用Ollama镜像，Ollama是一个本地模型运行时，支持Llama、Qwen、DeepSeek等一众开源模型。

在WSL2里执行：

bash复制docker run -d \
  --name ollama \
  -p 11434:11434 \
  -v ollama-models:/root/.ollama \
  ollama/ollama

拉模型和运行模型都通过ollama命令行完成。进容器执行或直接Windows执行ollama命令都行：

bash复制docker exec -it ollama ollama run deepseek-r1:7b

Ollama启动模型后，会监听11434端口，Windows这边就能通过localhost:11434访问。这个方案的好处是模型文件放在ollama-models卷里，容器重建模型不丢；坏处是镜像本身在Docker Hub，拉取时需要加速器配合。

如果你有NVIDIA显卡，且安装了支持WSL2的NVIDIA驱动，还可以加--gpus all参数让容器使用GPU，推理速度会快很多。不过这一步需要先确认驱动和WSL2的CUDA支持到位，Windows端和WSL2里的驱动版本要一致。

5.4 开发调试组合拳：VSCode + WSL + Docker

最后推荐一套开发工作流。VSCode可以直接连接WSL2发行版，在Linux环境里写代码、调试，Docker扩展负责管理容器。安装Remote-WSL扩展后，按F1输入“WSL: Connect to WSL”，VSCode就会以WSL2作为后端运行。这时候你打开的任何目录，都直接基于Linux文件系统。

在VSCode里装好Dev Containers扩展，还能直接把容器当开发环境。点一下容器ID，就能附着到容器内，进行代码调试。我实测这套流程非常适合做技术实验，比如跑Doris、Elasticsearch、YOLOv8推理服务，都是同一个套路：镜像拉取、容器运行、端口映射、VSCode附着调试。

另一个小技巧是，在Windows命令行里cd到WSL2路径时，直接用\wsl$\Ubuntu-22.04\home\xxx，很多工具可以直接对这条路操作，但也有些Windows原生程序（比如某些安装包、驱动工具）识别不了Linux路径，遇到这种情况就在WSL2里执行。

6. 高频问题排查与避坑速查

6.1 “virtualization support not detected”的六步排查

Docker Desktop启动失败提示“virtualization support not detected”或者“Docker Desktop failed to start because virtualization is not supported”，这是Windows部署Docker最常遇到的问题。按下面的顺序排查，基本能解决九成情况：

确认任务管理器里CPU虚拟化显示“已启用”。
BIOS里确认VT-x或AMD-V已开启。
关闭“内核隔离 - 内存完整性”功能后重启。
执行wsl --status检查WSL组件是否完整。
确认当前Windows版本不低于Win10 2004。
独立显卡驱动更新到最新，尤其是NVIDIA用户。

如果以上都做到位但还不行，考虑是系统里旧版Hyper-V残留冲突，可以执行bcdedit /set hypervisorlaunchtype off后再重启尝试。注意这个命令会影响依赖Hyper-V的其他功能，执行前先确认自己确实没有在用Hyper-V虚拟机。

6.2 “wsl needs updating … is too old”的解决办法

启动WSL2时提示“WSL needs updating. Your version of Windows Subsystem for Linux is too old”，通常是因为WSL内核太旧。新版WSL是独立组件，不像老版本那样只能依赖Windows更新。

解决方法分两步。第一步执行wsl --update，让WSL自动更新到最新版本。如果更新失败或卡住，去微软官网搜索“WSL2 Linux内核更新包”，手动下载并安装。第二步执行wsl --set-default-version 2，确保默认模式是WSL2。

装完之后重启WSL：

bash复制wsl --shutdown
wsl --status

看到状态正常，再启动Docker Desktop。我遇到过最顽固的情况是系统镜像被精简过，WSL组件缺失，这种情况下执行ws1 --install会报错，直接下载完整WSL安装包覆盖安装，再执行wsl --update。

6.3 端口占用怎么关：Windows下的定位三板斧

容器跑起来后，经常碰到端口冲突。最典型的场景是你已经在本机装了一个MySQL或Redis，再启动同名容器时发现端口被占用。Windows定位端口占用用三个组合命令：

bat复制netstat -ano | findstr :3306

列出的PID就是要找的进程，最后一列的数字是进程标识。再用：

bat复制tasklist | findstr 12345

确认这个PID是什么程序。如果确认可以关闭，执行：

bat复制taskkill /PID 12345 /F

这个三板斧适用于任何Windows端口占用问题。如果你觉得3306端口冲突反反复复出现，检查是否有服务自动重启，比如Windows服务里的MySQL或Redis。实在不想动本机服务，也可以换Docker容器的映射端口，比如-p 3307:3306，一劳永逸。

6.4 VSCode连不上WSL的常见原因

VSCode的Remote-WSL连接失败，最常见的原因有三个。第一个是WSL2发行版根本没启动，先手动执行wsl -d Ubuntu-22.04确认能进入终端。第二个是VSCode的Remote扩展只装在Windows端，没在WSL2里运行过，建议先安装Remote-WSL扩展，然后用“WSL: Connect to WSL”连一次，VSCode Server会自动部署到WSL2里面。第三个是WSL2网络状态异常，执行wsl --shutdown重启一次。

连接后如果发现终端里命令找不到docker，多半是因为Docker Desktop没有启用对应发行版的WSL Integration。回到Docker Desktop的Settings - Resources - WSL Integration里勾选发行版，保存重启即可。

提示：把VSCode的默认集成终端配置为WSL2的bash，平时命令行操作就在Linux环境里进行，比在Windows cmd里舒服很多。

6.5 高频问题速查表

问题	现象	快速处理
虚拟化未检测到	Docker Desktop启动失败	BIOS开启VT-x/AMD-V，关闭内存完整性
WSL版本太旧	启动报wsl needs updating	wsl --update，内核包覆盖安装
WSL2不可用	wsl -l -v显示版本为1	wsl --set-version Ubuntu-22.04 2
端口冲突	容器启动失败，提示port已分配	netstat定位PID，taskkill关闭占用
镜像拉取超时	docker pull卡住	配置registry-mirrors加速器
vmmem内存高	Windows卡顿	配置.wslconfig限制memory
Docker Desktop无法连接	docker命令报daemon错误	等桌面端启动完成，wsl --shutdown后再启动

写在最后：几个让我省下大量时间的经验

这套Windows + WSL2 + Docker环境，我前前后后重装过不下十次，最有价值的体会是把WSL2当成一台独立的Linux服务器来管理，而不是Windows的一个附属品。所有需要持久化的数据目录、脚本、配置，都放在Linux文件系统里，定期用tar打包备份；所有临时文件放在Windows侧，无所谓丢不丢。这样做以后，系统重装、换电脑迁移，成本极低，把整个WSL目录导出再导入就全回来了。

另一个值得养成的习惯是，装完Docker Desktop后第一时间配置.wslconfig和registry-mirrors，这两件事能让你少跟“慢”字打交道。最后再分享一个小技巧：如果你经常在Windows和WSL2之间切换文件，用wslpath命令把Windows路径转换成Linux路径，比如wslpath "C:\Users\xxx"，它会把盘符映射成/mnt/c/Users/xxx，脚本里写路径时就不会再迷路。这套环境是个底座，数据库、大模型、开发实验都建立在上面，底盘稳了，上面跑什么都不会慌。