做服务端开发的朋友，应该都体会过Windows和Linux之间反复横跳的痛苦。以前我在Win10上写代码，要么开虚拟机装个完整Linux，要么直接装双系统，来回切换真折腾。后来把WSL跑起来之后，配合VSCode做日常开发，Windows里直接敲Linux命令、跑脚本、部署服务，基本告别了双系统和虚拟机。这篇文章我就把一套能直接照抄的WSL基础环境配置方案完整记录下来，从安装、初始化、开发环境配套，到磁盘清理和常见报错处理，全部讲透。
这篇内容适合谁？如果你刚接触WSL，想在自己Windows电脑上搭一套稳定的Linux开发环境；或者你已经装了WSL但经常遇到安装慢、更新失败、磁盘空间不释放、VSCode连不上之类的问题，这篇都能帮到你。我尽量把每个步骤背后的原因也讲清楚，这样你遇到变化时能自己排查，而不只是照着敲命令。
1. 为什么需要一套“基础环境配置方案”
1.1 先搞清楚：WSL能解决什么、不能解决什么
WSL的全称是Windows Subsystem for Linux，也就是Windows下的Linux子系统。它让你不用装虚拟机、不用装双系统，直接在Windows里运行一个真正的Linux发行版。我用了几年下来，最大的体感是两条：第一，开发工具链可以完全统一了，Windows里写业务代码，Linux里跑编译、跑服务、跑脚本，两边无缝衔接；第二，IO性能比传统虚拟机方案好很多，尤其是WSL2，文件读写速度在日常开发场景下基本可用。
但它不是万能的。WSL不适合跑对硬件直接操作的程序，比如依赖USB设备深度交互的嵌入式烧录工具、需要完整图形界面的Linux桌面应用，这些场景仍然建议用虚拟机或者真机。另外，如果你要长期跑生产级别的Docker服务，WSL2后端的Docker Desktop也只是适合本地开发和验证，和物理Linux服务器的行为还是有一点点差异。理解了边界，你就不会装完WSL后觉得“怎么这也不行那也不行”，它只是把你日常80%的Linux需求接住了。
1.2 WSL 1和WSL 2怎么选
WSL有两个大版本，理解它们的区别非常重要。WSL1是一个系统调用翻译层，把Linux的系统调用翻译成Windows的调用，好处是启动快、占资源少、文件可以直接在Windows路径下访问，而且不需要虚拟化功能；缺点是很多依赖完整Linux内核的软件跑不了，比如Docker、需要特定内核模块的工具，性能上也有瓶颈。
WSL2则是一个轻量级虚拟机，里面跑了一个完整的Linux内核，兼容性大幅提升，Docker可以直接跑，绝大多数Linux软件都能装。代价是启动稍慢一点、内存占用更高，而且WSL2里的文件系统放在一个虚拟磁盘里，Windows访问这个虚拟磁盘里的文件会比访问普通Windows目录慢一些。
我的建议很直接：新环境一律用WSL2。除非你电脑是老古董、不支持虚拟化，或者你只需要跑一些简单的命令行工具，否则没有必要回头用WSL1。我在公司给同事配环境时，也会明确告诉他们优先WSL2。
1.3 我推荐的基线配置：Win10 22H2 + WSL2 + Ubuntu 22.04
做技术方案最怕“每个人环境都不一样”，出了问题不好排查。我自己在Windows 10 22H2这个版本上测试过多次，配合Ubuntu 22.04 LTS作为默认发行版，整体非常稳定。为什么选Ubuntu 22.04而不是最新的24.04？因为很多第三方软件和教程的适配节奏没那么快，22.04的软件源、依赖库资料最全，遇到问题能搜到大量现成答案。
Win11系统也能用同样方案，步骤几乎一致。Win10 长期企业版、家庭版、专业版我都试过，只要你开启了下面的Windows功能，基本都能正常使用。不过版本太老的Win10（比如1803之前），建议还是先把系统更新一下再折腾WSL，否则会遇到内核组件缺失的问题。
2. 安装与初始化：从零到能跑代码
2.1 开启Windows功能，一步都不能省
很多人装WSL失败，问题往往出在第一步——没有正确开启Windows功能。你需要确保“适用于Linux的Windows子系统”和“虚拟机平台”这两个功能都开启。推荐用管理员权限打开PowerShell执行：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart第一行是开启WSL功能，第二行是开启WSL2所需的虚拟机平台。执行完以后重启电脑。这里特别提醒一句：不要偷懒只开第一项，否则就算你装了发行版，也只是WSL1，后面想升到WSL2还得补开虚拟机平台再重启一次，白白浪费时间。
重启之后，在PowerShell里把默认版本设为WSL2：
wsl --set-default-version 2如果提示找不到WSL命令，说明你的系统自带WSL版本太老，需要先更新WSL本体。至于是直接装最新WSL还是走系统更新，我放后面“常见问题”里详细讲。
2.2 在线安装卡住怎么办：离线包和导入
系统版本较新的话，一条命令就能装默认发行版：
wsl --install -d Ubuntu但很多人会遇到一个问题：命令执行后一直卡在下载阶段，速度慢得像蜗牛。根本原因其实不是WSL本身的问题，而是你的网络环境到这个下载源之间的链路不稳定。这种时候不要死等，我有两套替代方案。
第一套方案是手动下载发行版安装包。到微软官方的WSL发行版页面下载Ubuntu的Appx包，或者用在线商店下载，然后把它放到一个本地目录，把后缀改成zip解压，运行里面的ubuntu.exe完成安装。这个方式绕过了wsl命令默认的下载流程，对网络环境更友好一些。
第二套方案是去另一台已经装好Ubuntu的机器上，用wsl --export导出一个tar包，拷贝回来wsl --import导入。这种方式特别适合公司内网、多台机器批量配置的场景，因为导出的环境可以提前配置好软件源、常用工具，导入后直接就能用。我喜欢把这种方式叫“环境快照”，从零配置一台新机器的时间能从半小时压缩到五分钟。
给一个导入导出命令的参考：
# 在源机器导出 wsl --export Ubuntu ubuntu-backup.tar # 在目标机器导入，安装到D:\WSL\Ubuntu wsl --import Ubuntu D:\WSL\Ubuntu ubuntu-backup.tar注意，用wsl --import导入的分发版默认用root用户登录，且没有默认的初始用户配置，拿到手后还需要自己创建普通用户，这个我下一节会说。
2.3 安装后的第一轮设置：换源、建用户、改位置
装好Ubuntu，进入WSL终端，我做的第一件事永远是换软件源。Linux环境下，软件源的下载速度直接影响你后续装任何东西的体验，默认官方源在国内环境下经常慢到让人怀疑人生。我会把apt源换成国内常用镜像源。
操作方式很简单：编辑/etc/apt/sources.list，如果是Ubuntu 22.04，把archive.ubuntu.com这些默认地址替换成mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn对应的地址。具体格式根据版本略有差异，22.04之后新版apt源加入了jammy等代号路径，照着官网的镜像帮助页改就行。改完执行：
sudo apt update && sudo apt upgrade -y这时候顺便把基础工具装齐：
sudo apt install -y build-essential git curl wget net-toolsbuild-essential包含gcc、make等编译工具链，是后面编译任何软件的基石。git和curl、wget则是日常开发必备，装好就不用来回折腾了。
接下来处理用户问题。如果是正常安装的Ubuntu，安装过程中会让你设置用户名密码，这一步按提示来就行。但如果你是wsl --import导入的环境，需要手动创建一个普通用户：
sudo useradd -m -s /bin/bash yourname sudo passwd yourname然后设置默认用户。以Ubuntu为例，可以用distro-launch的命令设置，或者在/etc/wsl.conf里加一行配置。我个人更推荐用/etc/wsl.conf的方式：
[user] default=yourname保存后退出终端，执行wsl --shutdown，再重新进入就是你的普通用户了。为什么强调用普通用户？因为root用户操作没有边界感，文件权限混乱是小事，误删系统文件就是大事。开发环境还是养成一个好习惯。
2.4 限制WSL2的内存和CPU，避免被吃满
WSL2本质上是个虚拟机，默认情况下它会使用Windows可用内存的一部分，在配置高的机器上，WSL2吃内存的现象会很明显。我记得有一次忘了限制，打开WSL后Windows 16G内存直接被吃了8G，开浏览器都卡。好在WSL2支持通过一个配置文件限制资源。
在Windows用户目录下新建.wslconfig文件，写入：
[wsl2] memory=4GB processors=4 swap=8GB localhostForwarding=truememory是WSL2最大内存，processors是最大CPU核数，swap是交换分区大小。这里的数值根据你机器实际情况调整，我一般建议内存不超过物理内存的一半，CPU核数保留给Windows至少两个核。写完后执行wsl --shutdown，重进WSL生效。
这个文件在WSL1下无效，因为WSL1不算虚拟机，资源管理方式不同。另外，这个限制只对WSL2生效，如果你混合使用了WSL1和WSL2，要注意区分。
2.5 把VHDX移到非系统盘，给C盘腾空间
WSL2的Linux文件系统存放在一个vhd虚拟磁盘文件中，默认位置在C盘用户目录下。随着你往WSL里装各种环境，这个文件会越来越大，C盘空间会被一步步吃掉。我见过一个同事的WSL虚拟磁盘涨到60多G，C盘直接变红。这时候最靠谱的解法是把vhd文件迁到其他盘。
流程分为三步：先导出，再导入到新位置，最后删掉旧的发行版。导出导入命令我在上面已经给过，关键点是导入时指定安装路径：
wsl --export Ubuntu ubuntu-backup.tar wsl --unregister Ubuntu wsl --import Ubuntu D:\WSL\Ubuntu ubuntu-backup.tarwsl --export会生成一个完整的tar快照，wsl --import把它恢复到指定目录。这样做之后，原来的vhd文件可以通过wsl --unregister清掉。注意，wsl --unregister会删除该发行版的所有数据，执行前务必确认导出包已经成功生成。我自己操作过几十次，这个方案非常稳，但它会把WSL的初始用户设置重置，所以迁移后记得检查默认用户和wsl.conf配置。
3. 开发环境配套：把WSL真正用起来
3.1 VSCode + WSL，远程开发的标准姿势
装好WSL只是开始，真正让它变成日常开发环境还要配好编辑器。现在最主流的方案是VSCode搭配WSL扩展，使用体验和直接在本机写代码几乎没区别。
先在Windows侧装好VSCode，再在扩展市场搜索“WSL”安装微软官方的WSL扩展。打开WSL终端，进入你的项目目录，输入：
code .VSCode会自动连上WSL，打开一个远程窗口，左下角会显示“WSL: Ubuntu”。在这个窗口里打开的终端就是WSL里的bash，可以直接跑Linux命令，文件树也是Linux视角。这个方案的好处在于，所有的编译、调试、运行都发生在Linux环境里，但编辑器界面还是Windows桌面的流畅体验。
有几个细节值得注意：第一，项目文件最好放在Linux文件系统内，也就是/home/用户名下，不要放在/mnt/c里，后者是Windows文件系统的挂载，跨文件系统读写在WSL2下会比较慢；第二，VSCode的插件建议在WSL侧也装一份，比如Python扩展、ESLint这类依赖运行时的插件，在远程窗口里点安装就是装到WSL环境；第三，如果打开WSL项目时提示找不到某个命令，往往是PATH问题，检查一下你的shell配置文件~/.bashrc里有没有把node、python、go等工具的路径加进去。
3.2 终端和字体：接近macOS体验的配置
写代码这件事，终端和字体的观感会影响一整天的心情。很多从macOS切到Windows的人，最不习惯的就是Windows Terminal里那种默认字体看起来“不够清晰”，代码阅读总觉得差了点什么。其实Windows Terminal完全可以调到接近macOS的观感。
字体方面，我最推荐Cascadia Code，这是微软官方的等宽字体，自带连字，配合Windows Terminal用起来很舒服。如果你喜欢更接近macOS里SF Mono的观感，可以试试JetBrains Mono，它的字母间距和清晰度都非常优秀。我是用Cascadia Code作为主力字体，配上Powerline风格的主题，效果非常干净。
设置路径：打开Windows Terminal，按Ctrl+,进入设置界面，找到配置文件里的外观项，把字体改成Cascadia Code，字号设为14。背景色我习惯用深色主题，透明度稍微调低一点，代码块的高亮会更明显。如果你用zsh，还可以装oh-my-zsh配合主题，让bash的提示符也别那么素。不过要提醒一句，不要为了花哨装太多zsh插件，扎扎实实的编辑环境比华丽的提示符更有用。
3.3 典型服务部署：Redis安装示例
WSL装本地服务非常方便，我用Redis举个例子。很多人一开始在Windows下编译Redis，各种依赖问题搞到崩溃，但在WSL里就是几行命令的事：
sudo apt update sudo apt install -y redis-server sudo service redis-server start redis-cli ping如果返回PONG，说明服务已经跑起来了。默认配置下Redis监听在127.0.0.1:6379，WSL2会把Linux里的端口自动转发到Windows的localhost，所以你Windows侧的代码连localhost:6379就能访问到WSL里的Redis。端口转发这个特性是WSL2自带的，我实测下来Redis、MySQL这类服务都能正常用。
如果要在WSL里改Redis配置，比如设置密码、修改监听地址，编辑/etc/redis/redis.conf，改完用sudo service redis-server restart重启即可。这里有个坑：有些教程让你用systemctl管理服务，但WSL默认没有systemd，用不了systemctl。WSL里管理服务统一用service命令就好。不过新版本的WSL已经支持systemd了，开启方式是在/etc/wsl.conf里加：
[boot] systemd=true改完wsl --shutdown再进来，systemd就能用了，很多依赖systemd的软件安装部署会更顺利。
3.4 开发场景扩展：CUDA、协议分析、跨平台编译
WSL2还有一个大杀器就是支持CUDA跑GPU计算。NVIDIA官方对WSL的支持已经非常成熟，Windows侧安装驱动后，WSL里直接装CUDA Toolkit就能利用GPU，无需在WSL里再装显卡驱动。我见过不少搞机器学习的朋友，笔记本Windows上直接WSL里跑深度学习训练，效果和Linux裸机基本一致。如果你用的是WSL1，这条就不要想了，GPU支持只属于WSL2。
嵌入式分析和安全方向的朋友经常提到binwalk。这个固件分析工具要在Linux下跑，Windows下很难直接装。在WSL里执行：
sudo apt install -y binwalk就能用它分析固件、提取文件系统了。我做过几次路由器固件的分析，WSL里跑binwalk比在虚拟机里流畅很多。
再比如一些Android播放器相关的编译任务，像ijkplayer这种需要Linux编译环境的项目，WSL里配合NDK工具链也能完成。核心点在于WSL2拥有接近原生的Linux内核，大部分编译工具链都能跑，唯一的瓶颈可能是文件系统IO，编译时把中间产物放在Linux分区内，速度会有明显提升。
4. 磁盘空间治理：删了文件空间为什么没释放
4.1 ext4.vhdx的“只增不减”现象
用WSL2一段时间后，很多人会发现一个奇怪现象：明明在WSL里删了一堆文件，Windows侧C盘的空间却没有变多。原因在于WSL2的整个Linux文件系统都放在一个ext4.vhdx虚拟磁盘文件里，这个文件会随着使用自动增大，但删除文件时，它只会把磁盘内部标记为空闲，不会自动把容量让出来给Windows。就好比你在一块硬盘上删了文件，但分区大小不会自动缩小。
想确认空间占用情况，进入WSL执行df -h看文件系统使用率，再到Windows侧看ext4.vhdx的实际大小，两者一对比，你就知道磁盘文件“膨胀”了多少。如果vhd大小和使用量相差几个G甚至十几个G，说明你的虚拟磁盘里积压了大量空洞空间，可以考虑手动压缩。
4.2 手动压缩VHDX的正确流程
压缩ext4.vhdx有两条路径。最简单的一条是在WSL内部先执行：
sudo fstrim /这条命令会通知虚拟磁盘“哪些块是空闲的”，为后续压缩做准备。然后在Windows侧管理员PowerShell执行：
wsl --shutdown diskpart # 在diskpart交互窗口里执行： # select vdisk file="C:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_xxx\LocalState\ext4.vhdx" # attach vdisk readonly # compact vdisk # detach vdisk注意，select vdisk后面要写你实际的vhd路径，路径里的发行版名不同会有差异。整个过程不会影响WSL里的文件，我已经跑过很多次了，可以放心操作。压缩完再看vhd文件大小，通常会明显缩小。
如果你迁移过发行版到D盘或其他目录，记得去实际位置找ext4.vhdx。还有一种情况要特别注意：如果WSL里启用了systemd，wsl --shutdown后有些服务可能没有完全退出，压缩前最好把Docker Desktop这类依赖WSL的程序先关掉。
4.3 从源头控制体积的几个习惯
压缩虚拟磁盘属于事后补救，真正省心的是从源头控制WSL的体积。我有几个习惯，分享给大家。
第一，不要把大文件放在WSL的home目录里，比如模型文件、镜像包、安装包，都放到Windows侧目录，用的时候再引用。WSL的磁盘增长容易，缩回去要麻烦很多。第二，定时做清理，apt的安装缓存会越积越多，sudo apt autoremove和sudo apt clean可以清掉大量无用包和缓存。第三，如果你只是用WSL跑几个简单命令，尽量装轻量工具，不要见什么装什么，环境越干净，问题越少。
我见过一个极端案例，同事在WSL里装了一套完整的图形界面，还拉了十几个Docker镜像，vhd直奔100G。这种场景真的不建议在WSL里做，图形界面用RDP到远程服务器或者用完整虚拟机，体验会更好。
5. 常见问题排查清单
5.1 安装过程中出现的403和更新超时
很多人运行wsl --install或wsl --update时遇到过403或者长时间卡住的情况。403报错一般出现在网络代理环境或者组织策略限制的场景，本质上是请求被拦截了。如果你在办公网里，先确认有没有网络策略限制外网访问；如果是家用网络，可以试试管理员身份运行PowerShell，有时候权限不足也会导致类似问题。
wsl --update下载很慢是另一个高频问题。这个更新包体积不大，但下载源在国外，有时候网络波动就会卡住。替代方案有两个方向：一是将Windows系统更新到较新版本，让WSL组件随系统一起更新；二是使用离线安装包手动更新WSL，从微软官方渠道下载对应的msi安装包或商店安装包，本地执行安装。离线包方式不依赖网络稳定性，我一般认为是最省心的。
有一种情况容易误判：执行wsl --list --online连接超时，很多人以为是WSL本身坏了，其实这条命令只是去拉取可安装发行版列表，网络不通自然超时。你完全可以跳过它，直接用wsl --install -d Ubuntu指定发行版名称安装，或者走离线包方案。
5.2 “WSL is too old”怎么处理
做WSL配置，我见过最多的一条报错是：Your version of Windows Subsystem for Linux (WSL) is too old. Run the command wsl --update to update to the latest version.
出现这个提示，说明你Windows里的WSL组件版本偏低，但系统本身可能没有开放自动更新WSL的通道。处理方式：先用wsl --update尝试更新，如果这个命令也报错或者卡住，按上面说的离线安装包方式手动升级。还有一个隐蔽的坑：有些精简版Windows系统把商店组件干掉了，WSL的更新入口就失效了，这种系统想用完整的WSL2比较困难，我会建议优先考虑完整版原版系统，或者评估当前系统是否真的适合作为开发主力机。
升级完以后执行wsl --status查看当前WSL版本，如果显示内核版本正常，一般就解决掉了。
5.3 Docker Desktop提示WSL unresponsive
Docker Desktop在后端使用WSL2时，偶尔会弹窗提示WSL is unresponsive。这个问题的直接解释是Docker Desktop轮询WSL服务超时了。
我推荐的排查路径是：第一步，把Docker Desktop完全退出，不只是关窗口；第二步，在PowerShell里依次执行wsl --shutdown，彻底重启WSL；第三步，重新打开Docker Desktop看看能否正常启动。这一步能解决大部分“假死”状态。
如果还不行，进入WSL里检查Docker服务状态：
docker version看到Server段信息正常，说明WSL和Docker都活着。问题多半出在Docker Desktop和WSL之间的通信。这时可以考虑更新Docker Desktop版本，或者切换Docker Desktop的WSL整合设置，取消再重新勾选Use the WSL 2 based engine，重启软件。老版本WSL内核会导致Docker后端不稳定，确认WSL已经更新到最新版也很有必要。
5.4 Hyper-V相关错误（HCS_E_HYPERV_NOT_INSTALLED）
WSL2启动时如果报错HCS_E_HYPERV_NOT_INSTALLED，意思很明确：当前系统没有开启Hyper-V或虚拟机平台，WSL2无法创建虚拟机。常见于某些系统版本默认没开启虚拟化组件，或者BIOS里关闭了虚拟化技术。
处理办法分三步：第一步，确认BIOS里Intel VT-x或AMD-V已经开启；第二步，在Windows功能里勾选虚拟机平台和Hyper-V（如果系统版本支持）；第三步，重启电脑。如果BIOS虚拟化被禁用，无论你怎么装WSL2都起不来，这一点在有些品牌机的默认设置上特别容易踩坑。
有的系统执行wsl --set-default-version 2时也会提示需要开启虚拟机平台，同样的处理思路。另外，Windows家庭版默认不带完整的Hyper-V管理器，但虚拟机平台这个功能是有的，开启后WSL2就能正常跑。我之前在某台Win10家庭版上就是这么搞定的。
最后再分享两个实际工作中的体会
第一，WSL配置文档不要只收藏不整理，建议把你自己机器上能跑通的命令和改动写成一个笔记，换机器时直接照着自己整理好的清单走，比重新搜问题快得多。第二，WSL环境虽然方便，但还是要给它设置边界，比如内存限制、磁盘位置、用户权限，提前定好规则，省得后面出了问题再大规模调整。这套WSL基础环境配置方案，说到底就是把这些规则和步骤固化下来，让Windows下的Linux开发体验既灵活又可控。
