从零配置WSL2 Ubuntu开发环境：安装、迁移与常用工具避坑指南

在Windows上折腾Linux开发环境，我试过双系统、VMware、Hyper-V，最后停在WSL2上没再换过。这东西说白了就是微软在Windows里内置了一个运行真正Linux内核的轻量级虚拟机，不需要装双系统，也不用开一个完整的VMware，打开终端敲个wsl就能进Ubuntu。这篇文章把我从零安装WSL2、下载配置Ubuntu的全过程写下来，包含版本选择、路径迁移、终端优化、中文输入法、Docker/CUDA/Ollama这些开发组件的配置，还有我踩过的那些坑，尤其是你如果和我一样，平时主要用Windows做桌面，但又离不开Linux那一套命令行生态（apt、bash、docker、内核特性），WSL2几乎是把两头的好处都占了。适合人群很明确：Windows用户想跑Linux开发环境、想玩容器又不想上虚拟机、或者团队里统一用Ubuntu但你电脑只能装Windows的人。

1. 整体思路拆解：WSL2凭什么能替代虚拟机

1.1 WSL2和WSL1、虚拟机、双系统之间怎么选

WSL2不是WSL1的简单升级，它是完全换了一套实现方案。WSL1做了一层系统调用翻译，把Linux程序发出的系统调用直接翻译成Windows内核能理解的调用，好处是启动极快、文件IO直接走Windows文件系统，但坏处也很明显：很多依赖Linux内核特性的软件（Docker、FUSE、systemd、eBPF）在WSL1里跑不起来或者行为怪怪的。

WSL2则是在Hyper-V虚拟化平台上跑一个轻量级虚拟机，里面是一个微软维护的、精简过的真实Linux内核。所以WSL2对Linux生态的兼容性接近完整，Docker、CUDA、systemd都能跑，这是它成为主流选择的最根本原因。我自己在WSL1时代折腾过很多次，动不动就遇到"这个工具需要内核模块"的问题，换到WSL2之后这些破事基本消失了。

如果你只是想要一个能敲Linux命令、跑脚本的环境，WSL1也许够用，但如今官方主推的就是WSL2，没必要再纠结。对比虚拟机，VMware的强项是完整的桌面环境、设备直通、网络隔离，适合做服务器实验、跑图形化Linux办公；而WSL2的强项是启动快、和Windows文件互操作方便、可以直接在Windows的IDE里调用Linux工具链。双系统则是终极方案，适合需要最大化性能、完全不打算同时用Windows的用户，但日常切换太痛苦。

1.2 什么场景不适合WSL2

把丑话说在前面，WSL2不是万能药。我见过不少人装了WSL2之后抱怨这不行那不行，其实很多情况是选错了工具。

第一，需要完整桌面体验的场景，比如要在Linux里跑一套完整的GNOME或KDE桌面做日常办公，WSL2虽然有WSLg支持GUI应用，但它不是为"桌面即服务"设计的，跑起来总有点隔靴搔痒。这种需求老老实实用VMware或双系统。第二，需要自定义内核模块、驱动开发的场景，WSL2虽然有真实内核，但这个内核是微软托管维护的，你没法随便加载自己编译的驱动模块。第三，需要直连物理硬件的时候，比如调试串口设备、插USB加密狗、做嵌入式硬件开发，WSL2的usbipd支持有限，配置成本高。第四，对磁盘IO要求极高的场景，比如跑大型数据库测试，WSL2的文件IO在跨文件系统时很慢，数据文件必须放在Linux虚拟磁盘里才行，而这个虚拟磁盘默认在C盘，容量管理也不如虚拟机灵活。

一句话总结我的思路：WSL2最适合的是"开发"而非"运行"，把代码放里面编译、跑服务、做测试，很舒服；但如果你想在Linux里做完整的桌面办公或者做内核级开发，别死磕WSL2。

2. 核心细节与实操要点：安装前你必须知道的事

2.1 检查Windows版本和虚拟化开关

安装WSL2之前，先确认两件事：Windows版本够不够新，CPU虚拟化有没有打开。Windows 10版本号2004（build 19041）及以上的64位系统，以及所有Windows 11系统，都原生支持WSL2。太老的Windows 10需要先更新系统，不然会遇到各种奇怪问题。

虚拟化这块是新手最容易卡住的地方。按Ctrl+Shift+Esc打开任务管理器，切到"性能"标签，点CPU，右下角会显示"虚拟化：已启用"或者"已禁用"。如果显示已禁用，需要进BIOS开启。开机时按Del或F2进BIOS（不同主板不一样），找CPU相关的设置项，Intel平台找"Intel Virtualization Technology"（VT-x），AMD平台找"SVM Mode"，把它设为Enabled，保存重启。有些游戏主板会把虚拟化藏在超频设置菜单里，比如微星的"OC -> CPU Features -> SVM Mode"，华硕的是"Advanced -> CPU Configuration -> SVM"，找不到就在BIOS里搜"SVM"或"Virtualization"关键词。

还有一个隐蔽坑：即使BIOS开启了虚拟化，如果Windows的Hyper-V相关功能没启用，WSL2也会报错。最简单的方式是在管理员PowerShell里执行bcdedit /set hypervisorlaunchtype auto，然后再开启功能组件。这个命令我后面安装步骤里还会用到。

2.2 三种安装方式怎么选

安装WSL2不用说网上一堆教程，但很多教程已经过时了。现在的推荐做法和以前不一样。

方法A，最简单，适合大多数人：管理员身份打开PowerShell或Windows Terminal，直接执行wsl --install -d Ubuntu-22.04。这一条命令会同时启用WSL功能、虚拟机平台组件，安装WSL2内核，然后下载并安装指定的Ubuntu发行版。执行完重启电脑，系统会在开始菜单里出现Ubuntu的图标，首次启动会让你设置用户名和密码。这个方式在Windows 11上体验最好，Windows 10也可以，如果命令提示不支持，就先用下面的方法B。

方法B，适合系统版本老、或者wsl --install失败的情况：先通过控制面板"启用或关闭Windows功能"勾上"适用于Linux的Windows子系统"和"虚拟机平台"两个选项，重启之后去微软官网下载WSL2内核更新包（x64 MSI），安装后打开PowerShell执行wsl --set-default-version 2，最后在微软商店搜索Ubuntu 22.04安装。这个方法比方法A多几个步骤，但对老系统的兼容性更好。

方法C，适合离线安装、公司内网、或者商店打不开的情况：手动下载Ubuntu的APPX安装包（可以在微软官网的WSL发行版列表页面找到），用Add-AppxPackage命令安装。

我个人的建议是优先尝试方法A，如果遇到报错，再退回方法B。最关键的是最后确认wsl --version能正常输出版本号，以及wsl --set-default-version 2执行成功，确保使用的是WSL2而不是WSL1。

2.3 Ubuntu版本选22.04还是24.04

热词里出现了"wsl2安装ubuntu22.04"、"wsl2 ubuntu24.04.4 lts更新"，说明很多人在这两个版本之间纠结。我的建议是：如果你不确定选哪个，就选22.04 LTS。

原因很实在。22.04是TLS版本，软件源里的包版本相对保守但稳定，很多工具链（尤其是ARM嵌入式工具链、ROS、CUDA toolkit）都在22.04上做了充分测试，预编译包的兼容性最好。24.04虽然是新版LTS，但系统库里默认的Python、GCC版本更高，个别老工具（比如某些vendor提供的SDK、特定版本的交叉编译器）还在适配中，万一哪个包在24.04的源里没有或者编译报错，排查成本很高。

如果你是做新项目、不想折腾、或者准备跑Docker、CUDA、Ollama这些对版本不敏感的工具，选22.04没毛病。如果你明确需要Python 3.12+或者GCC 13+这些新特性，选24.04也行，但要做好遇到兼容问题的心理准备。装完之后用lsb_release -a确认版本号，这个命令在排查很多问题时都要用。

3. 实操过程：从零装好WSL2和Ubuntu，再配成顺手的样子

3.1 两行命令装完WSL2和Ubuntu 22.04

前面说了方法A最简单，这里我把完整流程写一遍，方便直接照着操作。

第一步，右键开始菜单，选择"终端(管理员)"或"Windows PowerShell(管理员)"。第二步，执行wsl --install -d Ubuntu-22.04，然后等它跑完。这个过程可能持续几分钟，期间会自动下载WSL组件、Linux内核和Ubuntu镜像，需要有网络连接。第三步，提示重启就重启。第四步，重启后开始菜单里找Ubuntu图标，点击启动，正常会进入Ubuntu的初始化界面，设置一个用户名和密码，这个用户名不用非得和Windows用户名一致，它会成为Ubuntu里的管理员用户。

启动之后顺手验证几个东西：

# 查看当前WSL版本，确认是v2 wsl --list --verbose # 进入Ubuntu后查看系统信息 lsb_release -a uname -r

如果wsl --list --verbose显示版本号是1，说明默认WSL版本没设置好，执行wsl --set-version Ubuntu-22.04 2；如果显示"正在进行转换，这可能需要几分钟时间"，稍等一下，转换完成后WSL2就生效了。

还有一个小细节：首次进入Ubuntu后，系统会自动打开一个控制台窗口，让你创建UNIX用户。如果不小心关了窗口，或者没看到用户创建界面，以root身份重新进一次即可。在PowerShell里执行：

ubuntu2204 config --default-user root wsl

之后自己用adduser命令创建普通用户。这种"默认用户是root"的情况我在迁移系统时经常遇到，下面小节会详细说。

3.2 第一轮配置：换源、更新、装基础工具

装完Ubuntu之后别急着装东西，先把软件源换掉。原因不用多说，直连Ubuntu官方源在国内下载慢是常态，一个apt update可能要卡半天，镜像源和官方源里的内容是一致的，只是同步了一份在国内服务器上，速度完全不在一个量级。

编辑软件源前先备份：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo vim /etc/apt/sources.list

Ubuntu 22.04（jammy）的清华源内容大概是这样：

deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-security main restricted universe multiverse

如果是24.04，把jammy换成noble。保存后执行：

sudo apt update sudo apt upgrade -y sudo apt install -y build-essential vim git curl wget net-tools openssh-server ca-certificates apt-transport-https

build-essential会一并装好gcc、g++、make，这是后面编译各种东西的基础。net-tools里包含了ifconfig、netstat这些老牌命令，排查网络时很有用。openssh-server先装好，后面配SSH登录时用。

顺便提醒一句：apt upgrade可能会提示内核更新，WSL2下直接更新没问题，更新完重启WSL（wsl --shutdown再进去）就能生效。

3.3 把WSL2默认路径从C盘迁到D盘

这是热词里高频出现的一项。WSL2默认把整个Linux虚拟磁盘（ext4.vhdx）放在C盘用户目录下面，C盘空间紧张的话，装几个大点的软件就跑不动了。迁移方法并不复杂，但要注意操作顺序，折腾完别后悔。

先看当前存储位置：

# 在Windows PowerShell里执行 Get-ChildItem $env:LOCALAPPDATA\Packages -Filter "*Ubuntu*"

找到类似CanonicalGroupLimited.Ubuntu22.04LTS_xxx的目录，在里面的LocalState文件夹下可以看到ext4.vhdx文件，这就是整个Linux文件系统。迁移前先把WSL关掉，导出为一个tar备份：

# 管理员PowerShell wsl --shutdown wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar

然后注销这个发行版：

wsl --unregister Ubuntu-22.04

注意这个命令会删除现有的Linux系统，但没关系，我们已经导出备份了。接下来在D盘建一个目标文件夹，执行导入：

mkdir D:\WSL\Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar

导入完成后启动WSL，你会发现默认用户变成了root，这是因为import过程不保留原来的用户默认设置。解决办法是重新指定默认用户：

ubuntu2204 config --default-user 你的用户名

然后wsl --shutdown再重新进，用户就回来了。还有一种方式是在Ubuntu内编辑/etc/wsl.conf：

[user] default=你的用户名

修改后重启WSL同样生效。我这里强烈建议用第二种方式，因为再多一步wsl.conf里还可以配置网络、systemd等选项，后面会用到，一次性都配好。

3.4 终端和字体：把WSL的显示体验拉满

热词里有"wsl ubuntu写代码最推荐的字体接近macos的体验"，这一点我深有体会。WSL2命令行的默认观感，和macOS的Terminal/iTerm2差距主要在两方面：终端的渲染能力和字体。

终端方面，强烈建议用Windows Terminal替代老的conhost窗口。Windows Terminal在微软商店可以直接搜索安装，完全免费，它支持多标签页、GPU加速渲染、可定制配色，用起来顺手很多。装好之后在设置里添加一个新的配置文件，命令行指向wsl.exe，就是Ubuntu的入口，随时可以在PowerShell和Ubuntu之间切换。

字体是很多人忽略的细节。Windows下默认的Consolas在中文代码注释混排时非常难看，英文等宽不错但汉字比例古怪。macOS下Menlo和SF Mono看着舒服，是因为它们在等宽和可读性之间平衡得极好。Windows这边我推荐开源的Sarasa Term SC（更纱黑体终端版），它是一款专为终端混排设计的等宽字体，中英文对齐完美，和macOS下代码的观感已经很接近了。备选的还有JetBrains Mono和Cascadia Code，后两者是英文优先，看英文代码很爽，但中文注释就不太行。

Windows Terminal里设置字体很简单：打开设置 -> 配置文件 -> 默认值 -> 外观 -> 字体，下拉选择Sarasa Term SC，字号建议12或14。也可以在settings.json里直接改：

{ "profiles": { "defaults": { "fontFace": "Sarasa Term SC", "fontSize": 12 } } }

改完之后重启Windows Terminal，整体观感立刻提升一个档次。

3.5 中文输入法和WSLg图形界面

WSL2默认开启了WSLg，这意味着在WSL里运行的Linux图形程序能直接弹出窗口显示在Windows桌面上。既然有GUI，中文输入法就成了刚需，热词里"ubuntu中文输入法怎么设置"出现频率很高。

在WSLg下配fcitx5是最稳的方案。进入Ubuntu里执行：

sudo apt install -y fcitx5 fcitx5-chinese-addons fonts-noto-cjk

然后编辑~/.profile，在末尾加上环境变量：

export XMODIFIERS=@im=fcitx export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx

保存后执行source ~/.profile，再执行fcitx5启动输入法框架。之后打开任意GUI程序，切换到fcitx，就能用拼音输入了。

这里有个实际体会：在WSLg里跑Linux版微信或者输入法，体验终究不如Windows原生版本顺滑，尤其是字体渲染和输入法焦点切换，偶尔会有小毛病。所以我的建议是：如果只是为了和同事聊天，直接用Windows版微信就够了，不需要在WSL里装Linux微信；中文输入法主要是为了在WSLg里跑IDE、GUI调试工具时能输入中文，配好备用就好。

3.6 常用开发组件：Docker、CUDA、Ollama、geth、xvfb

聊完基础配置，再说几个高频需求。

Docker：WSL2跑Docker有两条路。最简单的是在Windows上安装Docker Desktop，然后在Settings -> Resources -> WSL Integration里打开Ubuntu-22.04的开关。之后在WSL里直接敲docker命令，它调用的其实是Docker Desktop的引擎，体验非常顺滑。另一种是直接在WSL里装Linux版Docker引擎，适合不想装Docker Desktop的场景，用官方脚本装即可：

curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER

注意如果要用systemd管理Docker服务，需要先在/etc/wsl.conf里开启systemd：

[boot] systemd=true

CUDA：热词里"wsl2安装cuda"也是高频。WSL2支持CUDA，前提是Windows端装好NVIDIA显卡驱动（普通游戏驱动就支持WSL），然后在WSL里安装CUDA Toolkit for WSL版本。安装完成后，nvidia-smi应该能在WSL里看到显卡信息，PyTorch/TensorFlow就能用GPU了。配置CUDA时注意：不需要在WSL里装显卡驱动本身，只装CUDA Toolkit即可，官方文档写得很清楚。

Ollama：在WSL2里装Ollama跑大模型非常方便：

curl -fsSL https://ollama.com/install.sh | sh ollama run qwen2.5:7b

如果CUDA配好了，模型推理会自动走GPU，速度比CPU快一个数量级。如果没有NVIDIA显卡，Ollama也能用CPU跑小模型，适合学习和开发测试。

geth：如果在WSL里做以太坊相关开发，可以装geth，通过官方PPA或直接下二进制都行。在WSL2里跑geth --dev作为本地开发链，配合systemd做后台服务，比在Windows里跑方便得多，临时开一个私链做合约开发测试完全够用。

xvfb：热词里有"wsl2安装xvfb"，这是做无头GUI测试和Selenium自动化常用的。安装很简单：

sudo apt install -y xvfb

然后配合WSLg可以玩出很多花样，比如在无头环境里跑需要显示器的测试脚本。

4. 常见问题与排查技巧实录

4.1 虚拟化未开启导致WSL2无法启动

报错信息是"WSL2 无法启动，因为此计算机上未启用虚拟化。请确保计算机固件设置中启用了虚拟化"。

这个错误在网上出现频率极高。排查路径从易到难：

先看任务管理器->性能->CPU->虚拟化是否"已启用"。如果显示已启用，问题在于Windows的Hyper-V功能没打开，管理员PowerShell执行bcdedit /set hypervisorlaunchtype auto，然后重启。

如果显示已禁用，需要进BIOS开启。不同主板的入口不同，Intel的VT-x和AMD的SVM名字不一样，但功能是一致的。有些电脑使用的是AMD平台，需要在BIOS里找SVM Mode并设为Enabled。注意，有些OEM机器（品牌机）的BIOS选项很少，如果不显示虚拟化选项，检查是否有BIOS更新，或者找官方支持文档。

有一点容易被忽略：开完虚拟化后如果Windows安全中心里内核隔离（内存完整性）开启，也可能影响WSL的虚拟化，可以先临时关掉测试。

4.2 老断网、DNS解析失败

WSL2默认使用NAT网络模式，这个模式在Windows重启后，WSL的虚拟网卡会重新分配IP，而且DNS解析时好时坏，表现就是"wsl2老断网"、"apt update超时"、"ping不通外网"。

排查第一步，在WSL里看当前DNS配置：

cat /etc/resolv.conf

正常应该看到nameserver指向一个内网IP（是Windows的虚拟网卡IP），如果这个IP不对或者内容是空的，网络基本就是废的。

解决方法：编辑/etc/wsl.conf，阻止WSL每次启动自动生成resolv.conf：

[network] generateResolvConf = false

然后手动写一个：

sudo rm /etc/resolv.conf sudo bash -c 'echo "nameserver 223.5.5.5" > /etc/resolv.conf'

223.5.5.5是阿里DNS，也可以换成114.114.114.114。改完wsl --shutdown再进，刷一下就好了。

如果你用的是新版WSL（0.67+），还有一个更优雅的方案：在Windows用户目录下创建.wslconfig配置文件，启用mirrored网络模式：

[wsl2] networkingMode=mirrored

开启后WSL共享Windows主机的网络栈，不再有独立IP，也不会因为IP变化断网，而且从Windows直接访问localhost就能连WSL里的服务，这是目前体验最好的方案。注意开启后需要wsl --shutdown再重启才生效。

4.3 ssh连接失败、xshell连不上WSL2

"ubuntu ssh无法连接"和"wsl2启动的虚拟机如何用xshell连接"是相关的问题。

要在本地用xshell/CRT连接WSL2里的SSH服务，需要做几件事。第一，确保SSH服务在运行：

sudo service ssh start

第二，编辑/etc/ssh/sshd_config，允许密码登录：

PasswordAuthentication yes

如果有需要，还可以改端口。第三，找到WSL2的IP地址，在WSL里执行wsl hostname -I，拿到IPv4地址，xshell里连接这个IP，用户名密码用WSL里的用户。如果密码登录被拒，确认sshd_config里没有错误，重启服务。

这个方案有个致命问题：WSL2是NAT网络，IP地址在Windows重启后会变化，今天配好的xshell连接明天就失效了。有两个解决办法：一是用4.2小节提到的mirrored网络模式，开启后WSL共享Windows的IP，xshell直接连localhost即可；二是Windows上配置端口转发，把Windows的某个端口转发到WSL的IP和22端口：

netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=22 connectaddress=WSL的IP

但WSL IP会变，还得把IP固定下来，麻烦。所以我个人建议：如果你日常用Windows Terminal已经能进WSL了，就别再从xshell绕一圈了；真要远程连，就上mirrored模式。

4.4 环境变量配置错误、gcc/cmake/numpy安装失败

这些属于Linux基础问题，但在WSL里出现频率很高，而且容易劝退新手。

环境变量配错了导致ls、vim都找不到，这种情况多半是改了~/.bashrc或者/etc/profile里的PATH，把原有的PATH覆盖掉了。解决办法是不靠绝对路径进系统目录找命令，用/usr/bin/ls或/usr/bin/vim救急，然后把改错的PATH行修复。避免踩坑的方法是：在.bashrc里追加PATH时用export PATH=$PATH:/new/path这种格式，不要写成export PATH=/new/path。

gcc安装失败，大概率是apt源的问题。先确认/etc/apt/sources.list里的源地址能不能访问，换源后apt update，再装build-essential基本不会失败。如果提示依赖关系无法满足，执行sudo apt --fix-broken install试试。

cmake版本太低，在WSL里做C++开发经常遇到，Ubuntu 22.04的官方源里cmake版本是3.22，有些新项目要求3.25以上。直接在kitware提供的apt源安装新版，或者pip install cmake。

numpy安装失败，热词里"ubuntu安装numpy 2.2.5"出现，这类问题大多因为Python版本过老：numpy 2.x要求Python 3.10+，如果系统默认Python是3.8，pip装新版本必然报错。解决思路是升级Python或者用pyenv建一个3.11/3.12虚拟环境，千万别在系统Python环境里乱装。在WSL里建议所有Python项目都用虚拟环境（venv/conda/pyenv），避免污染系统环境。

4.5 openclaw提示无法安全验证WSL2环境

"openclaw could not safely verify the wsl2 environment"这个报错在热词里出现，本质原因是openclaw工具在启动时检测不到WSL2环境，或者检测到当前环境存在异常。排查思路：

先确认WSL2本身正常：在PowerShell里执行wsl --version，若能正常输出版本号，说明WSL安装没问题。然后确认Windows的PATH中包含C:\Windows\System32，这个路径是wsl.exe所在目录，如果被某些软件改了PATH导致找不到wsl.exe，工具就会报类似错误。最后检查WSL版本是否需要更新，老版本的WSL内核和最新Windows版本不匹配时，各种工具都容易出现奇怪的验证失败。

解决办法：更新WSL（wsl --update），然后wsl --shutdown再重启WSL；如果还不行，卸载旧版WSL重新安装最新版本。这类工具报错大多数不是工具本身有问题，而是WSL环境处于一个"能跑但不标准"的状态，更新到最新版通常能解决。

4.6 WSL2里跑Zephyr和跨盘编译的注意点

热词里"ubuntu开发zephyr"是嵌入式开发的需求。Zephyr是一个嵌入式操作系统，官方推荐的开发环境是Linux，WSL2完全能跑，但要注意几个坑。

最大的坑是代码位置。很多人习惯把代码放在/mnt/c/workspace下面（Windows的C盘目录），在WSL里编译。WSL2的跨文件系统IO性能极差，在/mnt/c下跑west build，编译时间可能比Linux文件系统下慢好几倍。正确做法是把项目放在WSL的Linux文件系统里，比如/home/用户名/zephyr-project，用Windows侧的VS Code Remote-WSL插件打开，这样既能在Windows里编辑代码，编译又在Linux文件系统里完成，两边都能兼顾。

另外Zephyr需要装west、cmake、ninja以及arm-none-eabi-gcc等工具链，其中cmake版本要求较高，用21.04之后的方法安装比较好。如果编译时提示找不到Python模块，确认python3和pip都指向同一个版本，用python3 -m pip而不是pip。

4.7 其他值得记录的小坑

补充几个我在实际操作中遇到的问题，不一定有普遍性，但碰到过的人都懂。

WSL2里apt upgrade之后，偶尔会出现"bash: command not found"之类的诡异问题，十有八九是PATH环境变量被改坏了，救援手段是直接敲/bin/ls、/usr/bin/sudo这些绝对路径。Ubuntu里sudo的用户权限丢失，需要以root身份进系统，在Windows PowerShell执行wsl -u root，然后usermod -aG sudo 用户名加回来。磁盘空间不够，除了迁移WSL路径之外，还可以用wsl --manage <发行版> --set-sparse true开启稀疏虚拟磁盘，让ext4.vhdx自动回收未使用的空间。

再有一个是关于系统重装。热词里"ubuntu系统重装"出现不止一次，如果在WSL里把系统搞崩了，最干脆的办法就是wsl --unregister那个发行版然后重新装一个，反正配置文件都在Windows侧，代码提前推送到Git仓库，几十分钟又能恢复到干净状态。这也算是WSL2的一个优势：系统坏了不用重装Windows，直接删掉重来就行。

结语：我用WSL2的一点个人体会

前前后后折腾了挺久，我最想跟后来人说的一句话是：WSL2是把双刃剑，它消灭了双系统和虚拟机的大部分使用场景，但也引入了新的边界和坑，关键是要弄清楚哪里该用Linux侧，哪里该用Windows侧。我的经验是代码和项目文件老老实实放在Linux文件系统里，用VS Code Remote-WSL来编辑；Windows侧只负责终端、浏览器、Docker Desktop这些外围工具；网络和路径问题优先用.wslconfig的mirrored模式解决，别再跟NAT和动态IP作对。

如果你按照这篇文章的步骤走下来，应该会得到一个能日常开发的WSL2环境：能跑Docker、能用GPU、能跑大模型、能编译Zephyr和Linux内核，中文输入和显示也都在线。最后再分享一个小技巧：如果你经常在多台机器间切换，把/etc/wsl.conf和Windows侧的.wslconfig这两个文件的内容保存到自己的配置仓库里，新机器装完WSL直接用，能省掉很多重复劳动。