★ FEATURED ARTICLE 做服务端开发的朋友应该都体会过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里把默认版本设为WSL2wsl --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] defaultyourname保存后退出终端执行wsl --shutdown再重新进入就是你的普通用户了。为什么强调用普通用户因为root用户操作没有边界感文件权限混乱是小事误删系统文件就是大事。开发环境还是养成一个好习惯。2.4 限制WSL2的内存和CPU避免被吃满WSL2本质上是个虚拟机默认情况下它会使用Windows可用内存的一部分在配置高的机器上WSL2吃内存的现象会很明显。我记得有一次忘了限制打开WSL后Windows 16G内存直接被吃了8G开浏览器都卡。好在WSL2支持通过一个配置文件限制资源。在Windows用户目录下新建.wslconfig文件写入[wsl2] memory4GB processors4 swap8GB localhostForwardingtruememory是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多GC盘直接变红。这时候最靠谱的解法是把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:6379WSL2会把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] systemdtrue改完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 fileC:\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里启用了systemdwsl --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 unresponsiveDocker 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_INSTALLEDWSL2启动时如果报错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开发体验既灵活又可控。
阅读完成 · 觉得有帮助？
