如果你和我一样,既离不开 Windows 下的日常办公、游戏,又需要在 Linux 环境里写代码、跑脚本、用各种命令行工具,那你一定经历过这种纠结:装双系统,来回重启折腾到崩溃;开虚拟机,磁盘占掉几十 G,内存一开就爆,风扇转得跟飞机起飞似的。直到我认真用了 WSL,才觉得这两边终于能好好相处了。
WSL 的全称是 Windows Subsystem for Linux,简单说就是在 Windows 里原生跑一个 Linux 环境,不需要虚拟机那种完整的硬件模拟。尤其 WSL 2 改用了轻量级虚拟化方案,启动速度、文件读写性能、系统兼容性都比第一代强太多。这篇帖子我就把从零开始装 WSL、配置图形化界面、再到解决“一运行 Linux 内存就爆满”的完整过程写出来。我尽量把每一步的原理和执行逻辑讲透,不光是“照着做”,而是让你知道这一步是哪样、出了问题该往哪个方向排查。
先说好,我这套流程踩过的坑不少,尤其是内存占用那块,网上很多文章只给一个.wslconfig配置片段,但完全不解释为什么。这篇里我会把内存管理机制也讲清楚。不管你是刚开始接触 WSL 的小白,还是已经被 vmmem 进程折磨很久的老手,这篇文章应该都能给你一些有用的东西。
1. 我为什么放弃双系统和虚拟机,最终选择 WSL
1.1 双系统和传统 Linux 虚拟机的真实痛点
先聊聊我自己的血泪史。很多教程会告诉你“想用 Linux 就装双系统”,听起来很纯粹,但实际用起来特别分裂。你正在 Windows 里写一份文档、开了一堆浏览器标签页,突然需要切到 Linux 那边跑一个命令,只能保存所有工作、重启电脑,然后从引导界面里选 Ubuntu。等你跑完命令想回 Windows,又是一次完整重启。一天来回几次,人就麻了。
传统虚拟机则是另一套问题。VirtualBox 或 VMware 跑一个 Ubuntu 桌面版,动辄分配 4GB 内存、50GB 磁盘,实际体验还是吭哧吭哧的。桌面动画卡顿不说,宿主机内存一紧张,整个 Windows 都跟着掉帧。最要命的是文件共享,从 Windows 拖一个文件到虚拟机里,要么装增强工具、要么配共享文件夹,要么搞一个网络挂载,每个方案都有各自的脾气。
1.2 WSL 2 和虚拟机、双系统的本质区别
WSL 2 的思路完全不同。它不是把你整个 Windows 换掉,也不是在 Windows 里跑一个完整的 Linux 桌面,而是通过轻量级虚拟机技术,在 Windows 内核之上直接运行一个真正的 Linux 内核。这个方案的关键在于:
- 启动时间以秒计,不需要等待完整的开机自检过程。
- 内存是动态分配的。一开始只占很小一部分,你用多少它申请多少,理论上可以通过配置回收。
- 文件系统深度集成。你可以在 Windows 里用资源管理器直接打开 WSL 的目录,也可以在 WSL 里访问 Windows 的磁盘分区。
- Windows 10 和 Windows 11 原生支持,不需要第三方软件。
当然 WSL 2 也不是完全没缺点,最典型的就是跨操作系统边界的文件读写性能差。比如你用 WSL 里的命令去操作/mnt/c/下的 Windows 文件,速度会很慢。所以最佳实践是:代码工程放在 Linux 文件系统内部,Windows 侧只做查看和编辑。
1.3 什么场景下应该用 WSL 而不是别的方案
如果你需要跑图形界面复杂的桌面应用,比如要用到大量 GPU 渲染的 Linux 软件,那 WSLg(WSL 的图形支持)虽然能跑,但性能和兼容性还是不如真机或者虚拟机里的完整桌面。反过来,如果你主要是做后端开发、脚本处理、运维工具、跑 Docker 容器,或者用 Linux 的命令行生态,那 WSL 绝对是 Windows 平台上效率最高的选择。
拿我自己举例,我平时的开发工作大量依赖命令行:代码编译、git 操作、Python 虚拟环境、SSH 连接远程服务器、跑一些只能在 Linux 上运行的包。这些需求在 WSL 里全都完美覆盖。偶尔我需要打开一个图形化的文件管理器、看一张图片、跑一个带界面的编辑器,WSLg 也能直接调起来,完全不用再切系统。这种“在 Windows 里无缝使用 Linux”的体验,是双系统和虚拟机都给不了的。
2. WSL 完整安装实战:从启用 Windows 功能到跑起 Ubuntu
2.1 安装前的环境检查:你的电脑到底能不能装 WSL 2
动手之前先确认三件事,能省掉后面一大半的麻烦。
第一,Windows 版本。我用的是 Windows 11,WSL 2 的支持非常完整。如果你还在 Windows 10,需要确保系统版本不低于 2004 或者 20H2 才行,老版本可能要手动开启一些功能。检查方法很简单:在开始菜单里搜索“winver”,回车后会弹出一个小窗口,上面会显示完整的版本号。
第二,虚拟化是否开启。WSL 2 依赖 CPU 的虚拟化技术,也就是 Intel VT-x 或 AMD-V。大多数电脑默认开启,但如果你装过某些沙盒软件或者公司的安全策略禁了虚拟化,会导致 WSL 2 装完以后内核起不来,报一个“请启用虚拟机平台 Windows 功能”之类的错。检查方法:打开任务管理器,切到“性能”选项卡,选中“CPU”,右下角能看到“虚拟化”是“已启用”还是“已禁用”。如果是禁用,需要到 BIOS/UEFI 里找到 Intel Virtualization Technology 或 SVM Mode,把它打开。
第三,内存和磁盘剩余空间。WSL 2 运行一个基础 Ubuntu 系统,磁盘占用一般在 2GB 到 4GB 之间,加上后续安装开发工具和中间文件,至少要预留 10GB 以上。内存方面,虽然 WSL 2 可以动态分配,但如果你只有 8GB 内存,建议跑的时候不要同时开一堆大型软件,否则体验会很差,这在我后面讲内存优化的部分会细说。
2.2 最省事的安装方式:一条命令搞定
如果你用的是 Windows 11,或者版本合适的 Windows 10,现在最简单的安装方法是在 PowerShell 里以管理员身份执行这一条命令:
wsl --install这条命令会自动完成以下操作:
- 启用“适用于 Linux 的 Windows 子系统”功能。
- 启用“虚拟机平台”功能。
- 下载并安装 WSL 2 内核。
- 默认安装 Ubuntu 发行版。
装完以后,系统通常会要求你重启。重启完再打开开始菜单,应该能看到 Ubuntu 的图标。第一次点击进入,会进入一个类似 Linux 首次配置的流程,让你创建用户名和密码。这里注意,Linux 系统默认的超级用户是 root,但 WSL 里通常建议你用一个普通用户来操作,避免所有命令都拿最高权限跑,容易误操作改坏系统文件。输入用户名密码之后就完成了。
装完之后先别急着用,建议执行一次:
wsl --version确认一下 WSL 内核版本。如果输出显示 WSL 版本是 1.x 的老版本,说明你的环境里装的是旧版 WSL,需要手动更新。这时候 Windows 会提示你运行wsl --update。
2.3 老版本 Windows 或已有的旧 WSL 怎么升级
你要是之前装过 WSL 1,又不想直接重来,可以用管理员 PowerShell 执行:
wsl --set-default-version 2这条命令的意思是:之后所有新装发行版默认使用 WSL 2 架构。对已经装好的发行版,可以单独指定:
wsl --set-version Ubuntu-22.04 2转换过程可能需要几分钟,期间会提示你正在从 WSL 1 迁移到 WSL 2。这个迁移是比较平滑的,你的文件、已安装的软件包都会保留,只是底层架构换了,启动速度和性能会有明显提升。
如果你遇到的wsl --update下载速度特别慢,或者一直卡在某个百分比不动,我的经验是这样:
- 检查网络是否稳定,尤其是公司网络或校园网,可能有防火墙拦截了下载请求。
- 错峰重试。微软的更新服务器高峰期可能确实慢,换一个时段经常能秒下。
- 确认 Windows 系统时间、时区设置是否正确,时间偏移会导致 HTTPS 证书校验失败,更新也会卡住。
- 不要用任何第三方工具去加速下载,老老实实等官方服务器返回就行,这个过程一般不会超过十几分钟,卡太久大概率是网络策略问题。
2.4 离线安装 WSL 发行版:没有应用商店也能装
有些机器因为公司策略无法访问 Microsoft Store,或者你不想用商店的默认源,可以走离线安装的路线。流程如下:
先到微软官方文档页面下载 Ubuntu 的 WSL 离线安装包(扩展名是.appx或.msixbundle),然后在 PowerShell 里执行:
Add-AppxPackage Ubuntu.appx或者,如果你对默认发行版不满意,也可以使用 Linux 发行版厂商提供的 tar 包,通过wsl --import方式导入:
wsl --import <发行版名称> <安装目录> <镜像文件.tar>举个例子,你想把 Ubuntu 装到D:\wsl\ubuntu2204这个目录,镜像文件叫ubuntu2204.tar,命令就是:
wsl --import Ubuntu2204 D:\wsl\ubuntu2204 ubuntu2204.tar用--import方式导入的发行版默认以 root 用户运行,而且不会自动创建普通用户。如果你需要创建一个带 sudo 权限的日常用户,导入完成以后进入系统,执行:
adduser 用户名 usermod -aG sudo 用户名然后把默认用户改成刚才创建的用户。在 PowerShell 里执行:
ubuntu2204 config --default-user 用户名这样就能和商店版正常使用了。
3. 图形化界面两种方案:WSLg 原生体验与 VcXsrv 手动配置
3.1 先搞清楚原理:Linux 图形界面是怎么传回 Windows 窗口的
Linux 的图形界面体系和 Windows 不一样。Windows 底层是系统直接管窗口和绘图,而 Linux 桌面环境普遍采用 X Window System,后来又有了 Wayland。简单理解,Linux 是一个“显示服务器”加一堆“客户端程序”的结构。程序本身不知道屏幕长什么样,它只负责把绘图指令发给显示服务器,由显示服务器把它们变成像素画在屏幕上。
所以要在 WSL 里跑图形化程序,本质上要解决一个问题:WSL 里的 Linux 程序,怎么把绘图指令送到 Windows 的屏幕上?有两个常见途径:
一个是 WSLg。微软在较新的 WSL 版本里内置了一个完整的图形支持系统,自动把 WSL 里的 GUI 程序显示成 Windows 窗口,不需要你配置任何环境变量。另一个是自己装一个 X Server,比如 VcXsrv 或 Xming,然后在 WSL 里通过DISPLAY环境变量告诉程序“往哪个窗口服务发送绘图指令”。
3.2 Windows 11 用户的福利:WSLg 开箱即用
如果你用的是 Windows 11,而且 WSL 版本比较新,那么恭喜你,图形界面功能基本是装完就有的。你可以在 WSL 终端里直接输:
gedit或者装一个文件管理器试试:
sudo apt update sudo apt install nautilus nautilus如果一切正常,会弹出一个新的图形窗口,看起来就像一个普通的 Windows 程序。这是 WSLg 通过 Wayland 和 RDP 技术帮你把 WSL 里的图形界面“桥接”到 Windows 上了。
我用 WSLg 跑过 Qt 程序、PyQt 工具、甚至 VS Code 的远程窗口,体验都比较流畅。WSLg 还支持音频回传,如果程序发出声音,会直接通过 Windows 的声卡播出来,这比第一代 X Server 方案方便很多。
不过 WSLg 也有需要注意的地方:它默认使用 Wayland 作为主要显示协议,但很多 Linux 应用还停留在 X11 协议。WSLg 内部其实内置了 XWayland 来兼容这些老程序,所以你不一定需要自己操心。但如果某个程序在 WSLg 下显示异常,比如窗口大小不对、字体发虚,可以尝试安装一下:
sudo apt install xwayland然后重新启动程序,看是否解决。
3.3 Windows 10 用户的替代方案:VcXsrv 手动安装与配置
如果你还在 Windows 10,WSLg 用不了,也不用灰心,手动配置一个 X Server 是完全可行的。我用这台老机器跑 Windows 10 时就是这么干的,稳定运行了半年多。
第一步,下载 VcXsrv。它是一个开源 X Server,安装比较简单,一直下一步就行。装完以后在开始菜单里找到“XLaunch”,第一页选择“Multiple windows”,第二页选择“Start no client”,第三页保持默认,勾选“Disable access control”,一路完成。这里的“Disable access control”很关键,相当于让 X Server 不限制来源,WSL 里的程序才能随便连上来。
第二步,回到 WSL 终端,编辑 shell 配置文件:
echo "export DISPLAY=localhost:0.0" >> ~/.bashrc source ~/.bashrc如果你是先安装的 VcXsrv 后装的 WSL,那现在直接运行:
gedit应该能看到窗口弹出来。如果窗户没反应,先检查 VcXsrv 是不是还在运行,再检查DISPLAY变量是不是已经生效:
echo $DISPLAY输出应该是localhost:0.0。
第三步,处理 Windows 防火墙拦截问题。VcXsrv 首次运行的时候,Windows 防火墙通常会弹窗询问是否允许访问网络,这里一定要勾选“专用网络”和“公用网络”都允许,否则 WSL 内部的程序无法通过网络端口连回来,窗口就弹不出来。这一步我在第一次配置时吃过亏,防火墙弹窗没注意,直接点了取消,结果后面折腾半天才发现是流量被拦了。
3.4 图形化界面装好之后:中文字体、高分屏缩放和常见报错
图形界面能弹窗只是第一步,真正好用还得处理几个小问题。
首先是中文字体。Ubuntu 默认没装中文字体,打开中文文件名或者中文界面会显示成方块。解决办法:
sudo apt install fonts-noto-cjk sudo apt install fontconfig fc-cache -f装完之后重启图形程序就能正常显示中文了。推荐用 Noto CJK,它是目前 Linux 上支持中文最完整的开源字体族。
其次是高分屏缩放。如果你的 Windows 是 2K 或 4K 分辨率,且设置了 150% 或 200% 缩放,那 WSLg 或 VcXsrv 里跑的程序字体可能会非常小或者非常模糊。WSLg 会自动适配一部分,但老程序的适配就没那么好了。VcXsrv 的解决方案是在启动参数里加上:
-dpi 96或者根据你的缩放比例反推。比如 Windows 缩放是 150%,物理 DPI 大概是 144,那你可以设-dpi 144,窗口里的字体大小就会和 Windows 侧的风格更接近。WSLg 用户则可以设置每个程序的 GDK_SCALE 或者 QT_SCALE_FACTOR 环境变量,比如:
export GDK_SCALE=2 gedit就能把 GTK 程序强制放大两倍。
最后还有一个常见报错:cannot open display。出现这个,先检查 DISPLAY 变量,再确认 X Server 是否运行,最后检查防火墙。这三个环节几乎覆盖 99% 的显示连接失败问题。偶尔也会有 VcXsrv 启动时报缺失 DLL 的错误,通常是因为缺少 VC++ 运行库,去微软官网补一个 Visual C++ Redistributable 就能修复。
4. vmmem 进程吃掉内存的真相与解决内存占用的完整指南
4.1 为什么 WSL 刚一开始用,内存就直线飙升
很多人在任务管理器里看到一个叫vmmem的进程,内存占用常常几个 GB,明明自己什么操作都没做,它却一直驻留,这就是 WSL 2 在背后运行虚拟机进程。vmmem是 Hyper-V 虚拟机相关的进程,WSL 2 的整个 Linux 系统都跑在它里面。问题在于,WSL 2 默认的内存管理策略是:按需分配上限,但回收不及时。你装了几个包、跑了一次编译,内存被申请走,之后就算这些程序退出了,Linux 内核也不会主动把内存归还给 Windows。于是你看到的就是 vmmem 长期霸占几个 GB 内存,电脑越来越卡。
还有一个容易被忽略的原因:Linux 的文件缓存。你在 WSL 里读取或写入文件,Linux 内核会把数据页缓存在内存里,本意是提高后续访问速度,但这些缓存对 Windows 宿主来说是看不见也不好控制的,Windows 只看到 vmmem 占的内存越来越多。
4.2 核心方案:用 .wslconfig 限制并回收 WSL 2 的内存
针对 WSL 2 的内存问题,微软提供了.wslconfig配置文件。这个文件位于 Windows 用户主目录下,路径通常是C:\Users\你的用户名\.wslconfig。如果你从来没创建过,就手动新建一个,文件后缀是.wslconfig,注意是纯文本文件。
下面是我目前在用的配置,亲测稳定:
[wsl2] memory=4GB processors=4 swap=2GB swapFile=D:\\wsl\\swap.vhdx localhostForwarding=true autoMemoryReclaim=dropcache sparseVhd=true逐个解释一下:
memory=4GB:限制 WSL 2 最多使用 4GB 内存。值可以根据你的物理内存调整。如果电脑是 16GB 内存,日常跑开发任务多一点,建议设6GB或8GB;如果只有 8GB 内存,我建议设3GB或4GB。设置太小会直接导致 Linux 内部分程序 OOM(内存耗尽被杀掉),设置太大又失去了限制意义。经验算法:物理内存的一半左右,取一个舒适的上限。processors=4:限制 WSL 2 使用的 CPU 核心数。不限制的话,WSL 里跑高并发任务可能会把 Windows 侧也拖慢。设 4 到 6 个核足够日常使用。swap=2GB:这是 Linux 的交换分区大小。当内存不够时,Linux 会把不常用的内存页换到磁盘上的 swap 文件里。设 2GB 比较保守,可以再大一点,但没必要超过 4GB。swapFile:指定 swap 文件的存放位置。默认会放在系统盘,建议挪到非系统盘,减少对 C 盘空间的占用。localhostForwarding=true:允许 WSL 里的服务通过 localhost 端口被 Windows 访问。比如你把后端服务跑在 WSL 里,Windows 浏览器直接访问localhost:8080就能打开页面。autoMemoryReclaim=dropcache:这是解决内存不释放的核心参数。它告诉 WSL 2 在空闲时自动回收 Linux 中的内存缓存。dropcache模式会在检测到系统空闲时主动丢弃文件缓存,把内存还给 Windows。这个参数需要 WSL 版本较新才能用,实测在最新的 WSL 2 内核里效果非常明显。
配置改完以后,在 PowerShell 里执行:
wsl --shutdown然后重新进入 WSL,配置才会生效。如果此时去任务管理器看,vmmem 的占用应该会回落到一个合理范围。
4.3 实测对比:配置前后 vmmem 的内存占用差距
我以实际数据说明。我的电脑是 16GB 内存,平时开着 Edge 浏览器、VS Code、微信等软件,WSL 里跑一个 Go 后端服务和一个 Redis。没加.wslconfig之前,vmmem 稳定占用 5GB 到 7GB,Windows 整体内存经常逼近 95%,操作鼠标都有延迟感。加上配置和autoMemoryReclaim之后,vmmem 日常在 1GB 到 2GB 之间波动,跑任务时短暂冲到 4GB(正好是我设置的上限),任务结束后几分钟回落到 1GB 左右。
这里有一个细节要提醒:autoMemoryReclaim 不是立刻生效的,它需要 WSL 内核自动检测到系统空闲一段时间后才触发回收。如果你刚跑完一个大任务,切回 Windows 看内存还是高的,别担心,等几分钟或者用wsl --shutdown强行重启虚拟机,内存立刻释放。
4.4 手动应急:什么时候该用 wsl --shutdown,怎么避免丢工作
如果你不想等系统自动回收,或者内存真的已经紧张到 Windows 卡死,最快的方法就是在 PowerShell 里执行:
wsl --shutdown这条命令会强制停掉所有 WSL 发行版的生命周期。好处是内存瞬间全部还回 Windows,坏处也很明显:WSL 里所有未保存的工作都会丢失,包括你开着但没保存的 vim 状态、正在跑的本地服务、临时文件。所以我的建议是,别把这个当成日常操作,只用来应急。平时跑长任务前,要么在 Windows 上按 Ctrl+S 手动保存,要么确保关键数据已经写盘。
还有一个进阶玩法:用 Windows 任务计划程序定时执行内存回收。新建一个基本任务,触发器选“每天”,操作选“启动程序”,程序填wsl.exe,参数填--shutdown。不过这种方式有一个副作用,就是每天定时杀一次,如果你正好跑着一个编译任务,会直接被打断。我个人更推荐依赖 autoMemoryReclaim,只在特殊情况下手动干预。
4.5 从根源上减小 WSL 占用:关闭不需要的发行版、清理 apt 缓存和 Docker
内存限制解决的是“占用过高”的问题,但如果发行版本身臃肿,包缓存多得吓人,内存和磁盘都会有压力。有几个惯用的瘦身操作:
查看当前装了哪些发行版:
wsl -l -v如果某个发行版你平时根本不用,可以注销掉释放空间:
wsl --unregister Ubuntu-20.04注意:这会删除该发行版的全部文件,操作前确认没有需要保留的数据。
对于还在使用的发行版,进入系统后执行:
sudo apt clean这条命令会清空 apt 下载的软件包缓存,通常能省出几百 MB 到 1GB 不等。还有一个命令可以自动移除不再需要的依赖:
sudo apt autoremove如果你本身用 Docker,那么 Docker 的镜像和容器缓存也会占用大量空间。定期执行:
docker system prune可以清理未被使用的镜像、网络和构建缓存。这个命令偶尔会让 Docker 的首次启动变慢,因为本地没缓存了,需要重新拉镜像,但换来的是清爽的磁盘和内存。
5. 安装完成后的开发环境配置:VS Code、终端字体、Docker 与 CUDA
5.1 在 VS Code 里无缝使用 WSL:Remote-WSL 插件的正确打开方式
图形界面弄好了、内存问题也解决了,接下来最重要的一步,就是把 WSL 真正用进日常开发。我最推荐的方式是 VS Code 配合 Remote-WSL 插件。
插件的使用非常简单:在 VS Code 里搜索并安装“Remote - WSL”,安装完以后,左侧边栏会出现一个远程资源管理器图标。点开它,选择你当前的 WSL 发行版,VS Code 会自动重新连接,打开一个新的窗口,这个窗口里的终端、任务、调试器都是在 WSL 环境内运行的。你在 VS Code 里编辑代码,本质上是编辑 WSL 文件系统里的文件,而不是 Windows 侧的文件,这样代码的读写性能是最好的。
有人会问:我直接在 Windows 上打开一个本地文件夹,然后让它映射到一个 WSL 路径不好吗?我的建议是,尽量不要这么做。用 Remote-WSL 进入远端以后,你应该用 VS Code 的“打开文件夹”去访问/home/用户名/project这类路径,而不是去修改/mnt/c/下的文件。因为跨文件系统的编辑会频繁经过 Windows 与 Linux 之间的转换层,性能损耗非常明显。你把工程放在 WSL 的系统盘深处,Windows 这边通过\\wsl$\Ubuntu-22.04\home\用户名\project也可以查看,但编辑和编译都交给 WSL 侧完成,整个体验非常丝滑。
5.2 终端字体推荐:接近 macOS 写代码体验的两个选择
我把这个问题单独拎出来写,是因为它看似不起眼,实际对眼睛的疲劳度影响极大。在 WSL 终端里写代码,字体占一个很大比重。系统默认的字体比如 Consolas,看久了会觉得太方、太拥挤,对比 macOS 上那种圆润清秀的等宽字体,差距还是明显的。
我用了几个月的首选是 Cascadia Code,微软自家出品的等宽字体,自带 ligature(连字效果),现代代码风格很浓。在 Windows 终端里,默认就能选它作为字体,不需要额外安装。选中“Cascadia Mono”或者“Cascadia Code”之后,=>、!=这类符号会显示成漂亮的连字形式,看起来非常接近 macOS 上 JetBrains Mono 或 SF Mono 的效果。
如果你更喜欢更稠密、更清晰的字体,可以试试“Sarasa Term SC”(更纱黑体),它在中英文混排时表现极佳,中文不会出现严重的行高错位。安装方法:把下载好的.ttf字体文件放到C:\Windows\Fonts,或者在 Windows 设置里双击安装。然后在 Windows Terminal 的配置文件里把字体名称填进去,字符间距和行高随便调一调,就有了接近 macOS 的清爽感。
5.3 在 WSL 里跑 Docker:两种模式的抉择
Docker 是 WSL 的杀手级应用。开发时经常需要拉镜像、起容器,直接在 WSL 里装 Docker Engine 是可以的,但更主流、更省心的方案是使用 Docker Desktop 的 WSL 2 Backend。
Docker Desktop 安装后,在 Settings 里开启“Use the WSL 2 based engine”,然后到 Resources 的 WSL Integration 里,勾选你希望集成 Docker 的发行版。这样做的效果是:你在 WSL 终端里直接执行docker ps、docker run,实际操作的是 Windows 侧的 Docker Desktop 引擎。它有图形化管理界面,日志查看、镜像管理都很方便。
缺点是 Docker Desktop 本身也是一个不小的内存进程,如果你对内存敏感,可以换成纯命令行方案:直接在 WSL 里安装 Docker Engine。做法是进入 WSL,然后:
sudo apt update sudo apt install docker.io sudo service docker start这样跑 Docker 不依赖 Windows 侧的桌面程序,资源开销更省,但你需要自己管理 Docker 服务的启停,也没有图形界面看容器状态。我个人的经验是:如果内存大于 16GB、日常会频繁操作 Docker,就开 Docker Desktop 集成,图个顺手;如果机器配置一般、只是偶尔拉个容器跑个脚本,那就用纯命令行方案,省内存省到极致。
5.4 给跑 AI 和逆向分析的人一点参考:CUDA、binwalk 和 MOS
WSL 2 不只是能跑 Web 后端,还能用于一些相对重量级的场景。CUDA 这个关键词在搜索热词里经常和 WSL 一起出现,因为很多做深度学习的人想在 Windows 上用原生 Windows 版驱动跑 Linux 里的训练脚本。WSL 2 对 CUDA 的支持方案是:安装 Windows 侧的 NVIDIA 驱动,然后在 WSL 里安装 Linux 版 CUDA Toolkit,这样 WSL 就能直接调用 GPU 做计算。比起双系统来回折腾,这已经算非常轻量的 AI 开发环境了。
另一个我常用的场景是 CTF 和逆向分析。很多 CTF 工具链,比如 binwalk(固件分析工具)、GDB 的插件、各种 Python 逆向脚本,在 WSL 里天然就能跑。以前我在 Windows 下用这些工具,要么装 Cygwin,要么开虚拟机,要么用各种剥离工具,体验一言难尽。WSL 出现以后,直接在 Ubuntu 里apt install binwalk就完事了,和原生 Linux 一模一样,省心太多。
还有一些朋友问过我在 WSL 里部署 MOS 这样的多模态大模型。这类项目主要吃内存和显存,WSL 里只要配置好 CUDA 和足够的 RAM,跑推理脚本和原生 Linux 差别不大。不过如果模型体积特别大,比如几十 GB 的权重文件,建议把它放在 Windows 侧的独立分区,通过/mnt/d/访问,或者把 Linux 侧的 WSL 虚拟磁盘扩容到足够大,否则磁盘空间很容易紧张。WSL 的虚拟磁盘文件.vhdx默认放在系统盘AppData\Local\Packages\...目录下,你要是创建了大文件,C 盘空间就得提前规划好。
6. 最后的最后:一些我踩过坑之后才明白的小建议
WSL 看起来只是一个“容器”或者“子系统”,但它背后的虚拟化机制、文件系统边界、内存管理策略,每一项都值得花点时间理解。很多人上来就拷贝一段.wslconfig配置,内存问题确实解决了,但为什么解决、删掉哪句会回到原状,完全没有概念。做技术的人最忌讳的就是“能用就行”,一旦哪天环境出了新问题,你连排查方向都找不到。
我在长期使用 WSL 的过程里,总结了几个小习惯:
第一,尽量把开发工程放在 WSL 文件系统内部,Windows 侧的磁盘只当成一个“外接存储”来用。最典型的表现是,在 WSL 里cd /mnt/c/后执行npm install,速度会明显比在/home/下慢,特别是有大量小文件时差距更明显。养成这个习惯以后,很多莫名其妙的慢问题自然就消失了。
第二,定期检查 vmmem 的占用。正常情况它会随着任务涨落,但如果它长期高居不下,先看看是不是有 WSL 发行版在后台跑着某个服务。你可以用命令:
top进 WSL 里看有没有异常进程。也可以直接wsl --shutdown重置整个环境,再确认内存是否恢复正常。
第三,不要装太多发行版。WSL 支持多发行版同时存在,但每个发行版都有一份独立文件系统和可能的运行进程,占用的资源是叠加的。我见过有人为了体验不同系统,一口气装了 5 个 Ubuntu,结果光 vmmem 就占了 8GB,完全得不偿失。一个稳定的长期发行版加一个临时测试发行版,通常就够了。
第四,做好备份。WSL 的整个文件系统都封装在一个.vhdx文件里,你可以直接复制这个文件实现备份和迁移。官方提供了一个导出命令:
wsl --export <发行版名称> D:\backup\ubuntu.tar恢复的时候:
wsl --import <发行版名称> D:\wsl\ubuntu D:\backup\ubuntu.tar这个操作比虚拟机的快照还方便,强烈建议在环境配置好之后、工作沉淀之前导出一次,后面再怎么折腾都有后悔药。
我对 WSL 的评价是:它是微软这些年对开发者最有诚意的投入之一。它没有强行要求你放弃 Windows 去拥抱一个陌生系统,而是让你在熟悉的环境里,随时拉出一个完整的 Linux 工具链。把这篇文章从头到尾走一遍之后,你的 WSL 应该已经能做到启动快、图形化界面可用、内存占用可控、开发环境顺手。如果这通折腾对你有帮助,也不枉我踩过那些坑写下来。