WSL 2 + Ubuntu 开发环境：安装、Docker/GPU 与调优

1. 为什么到 2025 年我还在 Windows 上跑 WSL + Ubuntu

WSL、Ubuntu、Windows、Linux 这四个词凑在一起，基本就是现在大多数后端、运维、算法、嵌入式从业者的日常桌面形态。我自己的主力机从 2019 年开始就是 Windows 打底、Ubuntu 干活，中间换过三台机器、重装过七八次系统，踩过的坑足够写一本小册子。这篇就把 2025 年 10 月这个时间点上，Windows Subsystem for Linux 搭配 Ubuntu 的完整落地流程捋一遍，从装系统一直讲到日常写代码、跑容器、调 GPU，尽量做到你看完能直接照着敲。

先说清楚它到底解决什么问题。以前我们要在 Windows 上用 Linux，无非三条路：装双系统、开虚拟机、或者干脆买台机器单独跑。双系统每次切换要重启，虚拟机吃内存还掉性能，单独一台机器成本高、同步文件还麻烦。WSL 的思路完全不一样，它不是模拟一台完整的电脑，而是让 Windows 内核直接承担起 Linux 系统调用的翻译工作，Ubuntu 的用户态程序原生跑在 Windows 上面。你的bash、grep、apt、ssh都是真的，但不用重启、不用分盘、不用等虚拟机开机。

这套东西适合谁？我大概分三类。第一类是学生和刚入行的朋友，手上只有一台 Windows 笔记本，想学 Linux 命令、学 Git、学 Docker，又不想折腾分区和引导。第二类是从业多年的工程师，Windows 上有习惯的办公软件、截图工具、输入法，但开发环境必须待在 Linux 里，WSL 是唯一能让你两边都不割舍的方案。第三类是做 AI 和数据方向的，需要在 Linux 下用 CUDA、跑训练脚本，但笔记本是 Windows 本。这三类人加起来，基本覆盖了我身边九成的同行。

提醒：本文操作默认你已经能正常打开 Windows 终端（Terminal）或者 PowerShell，且登录的是有管理员权限的账号。公司电脑如果有统一的安全策略、组策略锁定，部分步骤可能被拦，这种时候先找 IT 确认，别硬来。

1.1 WSL、虚拟机、双系统到底怎么选

很多人一上来就问"我该用哪个"，其实这个问题没有标准答案，得看你每天的使用重心在哪。我把三种方案摊开对比一下，你对着自己的情况挑。

我个人的结论很直接：除非你要在 Linux 里跑完整的图形桌面、要做驱动级别的实验、或者要做内核调试，否则 2025 年没有理由不用 WSL。它的启动体验就像打开一个应用，这个差别用久了是回不去的。

1.2 WSL 1 和 WSL 2 的架构差异，别选错

这是最容易踩的坑之一。WSL 1 是"翻译式"的，Windows 内核直接把 Linux 系统调用翻译成 Windows 的对应调用，所以文件互访极快，但兼容性差，Docker 跑不起来，很多依赖特定内核特性的程序会报错。WSL 2 换了个思路，它内部跑的是一个真正的 Linux 内核，由微软维护，跑在一个轻量级虚拟化层上，兼容性几乎和原生一致，Docker、systemd 都能用，代价是跨文件系统访问时会慢一些。

具体差多少？我实测过一个场景：在 WSL 里对 5 万个小文件做递归遍历，WSL 1 大概 3 秒，WSL 2 大概 9 秒；但如果把文件放在 Linux 侧的文件系统里操作，WSL 2 只要 1.2 秒。结论很清楚——用 WSL 2，但代码一定要放在 Linux 自己的文件系统里，不要图方便放在/mnt/c/下面写，那是性能杀手。

提醒：默认情况下wsl --install装的就是 WSL 2。如果你机器上还留着老的 WSL 1 发行版，可以用wsl --set-version Ubuntu 2单独转换，转换过程要几分钟，期间别关机。

1.3 2025 年这套工具链的几个实际变化

这几年 WSL 的迭代速度其实挺快。我自己感受到的明显变化有几个。一是安装方式收敛了，早期要手动勾选"适用于 Linux 的 Windows 子系统"、再开虚拟机平台、再重启、再去商店找发行版，现在一条wsl --install基本搞定。二是内核更新走独立通道了，不用跟着 Windows 大版本一起升级，wsl --update就是一条命令的事。三是 systemd 支持转正了，这意味着你可以在 WSL 里用systemctl管理服务，跑 Redis、跑 Elasticsearch 这类需要常驻服务的场景友好很多。四是和 VS Code 的集成越来越顺，装个扩展就能把整个开发环境接过去。

这些变化加起来的直接结果就是：现在的安装门槛比三年前低了一大截，出错的地方也更容易定位。但反过来说，网上大量老教程还停留在旧流程上，你照着做反而会绕远路，这也是我写这篇的原因。

2. 安装前的准备工作与硬件软件门槛

动手之前花十分钟做准备，能省下后面一小时的排查。我见过太多人卡在"虚拟化没开"或者"C 盘满了"这种问题上，其实都是可以提前避免的。

2.1 系统版本、虚拟化开关与账号权限检查

先说版本要求。官方对 WSL 的支持门槛是 Windows 10 版本 2004（内部版本 19041）及以上，或者任意版本的 Windows 11。想用完整的wsl --install一条命令流程，最好升到较新的 Windows 11。查版本的方法很简单，按Win + R输入winver，回车就能看到版本号和内部版本号。

然后是虚拟化。WSL 2 依赖底层的虚拟化能力，如果 BIOS 里没开，后面会直接报错。检查方式是打开任务管理器，切到"性能"标签，点 CPU，看右下角有没有"虚拟化：已启用"。如果显示已禁用，就要重启进 BIOS，找到Intel VT-x、VT-d或者SVM Mode（AMD 平台）这类选项打开。不同主板菜单名字不一样，一般在 Advanced 或者 CPU Configuration 里面。

再确认一下账号权限。装 WSL 需要管理员权限，如果你登录的是受限账号，wsl --install会直接失败。判断方法是在 PowerShell 里敲一句：

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

返回True就是管理员，False就右键终端选"以管理员身份运行"再试。

提醒：有些笔记本出厂时 BIOS 里默认关掉了虚拟化，或者开了之后被厂商的安全软件又拦回去。如果你确认 BIOS 开了但任务管理器还是显示禁用，先检查是不是装了第三方安全防护软件在抢占虚拟化层。

2.2 磁盘空间规划与目录摆放策略

WSL 2 的发行版默认装在系统盘的用户目录下，一个干净的 Ubuntu 大概占 1.5 到 3 GB。但你真正用起来之后，装 Docker 镜像、跑数据集、编译项目，几十 GB 是很正常的事。我建议动手前先给系统盘留出至少 40 GB 空闲，长期用的话 100 GB 以上更稳妥。

如果你系统盘确实紧张，有两种办法。一是先把 WSL 装好，然后用导出导入的方式迁到其他盘，命令是wsl --export和wsl --import，这个我在第 3 章会详细说。二是提前把 Windows 的"应用安装位置"设置改成其他盘，不过这个设置对 WSL 是否生效在不同版本上表现不一致，实测不如导出导入可靠。

还有一个容易被忽略的点：WSL 的虚拟磁盘文件是一个叫ext4.vhdx的动态扩展文件，它只会变大不会自动变小。你删掉里面的大文件，Windows 这边的磁盘占用不会立刻释放。所以在规划空间时，要按峰值用量来留，而不是按当前用量。

2.3 终端与字体：先把敲命令的体验铺垫好

这一步不是必需的，但强烈推荐。默认的旧版控制台字体难看、中文容易错位、字符宽度对不齐，用久了眼睛累。我的做法是装 Windows Terminal（如果系统里还没有的话），然后在设置里把默认配置文件设成 Ubuntu，字体换成等宽字体。

关于字体，很多人想要接近 macOS 那种观感，核心其实就三点：字形宽度均匀、中英文对齐、行高舒服。市面上常用的等宽字体有 Cascadia Code、JetBrains Mono、Fira Code、Maple Mono 等。Cascadia Code 是微软自家出的，和 Windows Terminal 配合最省心；JetBrains Mono 的字形更圆润一些，接近 macOS 上的感觉。如果中英文混排要求高，可以找带中文的等宽字体，或者设置字体回退链。

在 Windows Terminal 的settings.json里可以这样写：

{ "profiles": { "defaults": { "font": { "face": "JetBrains Mono", "size": 12, "lineHeight": 1.2 }, "colorScheme": "One Half Dark" } } }

行高调到 1.2 左右是我试出来最舒服的值，默认的 1.0 会显得挤。这个设置改完之后，后面所有的命令行操作体感都会好一截。

3. 三条安装路线实测：从一键脚本到离线兜底

安装本身其实不复杂，但不同网络环境、不同系统版本的差异很大，所以我准备了三套方案。按顺序试，第一套不行就退到第二套，第二套不行再上第三套。

3.1 路线一：wsl --install 一条命令走通

这是 2025 年最推荐的方式，也是最省事的。以管理员身份打开 PowerShell 或者 Windows Terminal，敲：

wsl --install

回车之后它会自动做这么几件事：启用"适用于 Linux 的 Windows 子系统"和"虚拟机平台"两个可选组件、下载并安装 WSL 2 内核、把 WSL 的默认版本设为 2、下载 Ubuntu 发行版并完成初始化。整个过程大概需要几分钟，中途可能会弹一次重启提示，重启后会自动继续，进入 Ubuntu 的初始化界面，让你设置用户名和密码。

如果你想指定发行版，可以先看看有哪些可选：

wsl --list --online

输出里会列出 Ubuntu、Debian、Kali Linux 等一堆名字。装指定的那个就加参数：

wsl --install -d Ubuntu-24.04

这里有个细节要注意：-d后面跟的是发行版名称，必须和列表里的名字完全一致，大小写和连字符都不能错。

注意：Ubuntu 的用户名不要用中文，也不要用大写字母开头。密码输入时屏幕上不会显示任何字符，这是正常的，别以为键盘坏了。这个密码就是你的sudo密码，忘了的话后面要用 root 重置，比较麻烦。

3.2 路线二：手动启用组件 + 商店安装

如果wsl --install因为组策略、网络或者版本原因失败，可以拆开手动做。先启用两个 Windows 功能：

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

两条命令都返回成功之后重启电脑。重启完下载 WSL 2 内核更新包手动安装，然后在 PowerShell 里设置默认版本：

wsl --set-default-version 2

最后打开 Microsoft Store 搜索 Ubuntu，找到官方发布的那一个点安装，装完第一次启动同样会走一遍用户名密码初始化。这条路线的好处是每一步都能看到结果，出问题容易定位是哪一环卡住了。

3.3 路线三：离线包与导入导出兜底方案

有些环境完全连不上外网，或者公司网络对商店做了限制，这时候就得走离线路线。思路是：在一台能联网的机器上把发行版导出成 tar 包，拷到目标机器再导入。

导出命令在源机器上执行：

wsl --export Ubuntu D:\backup\ubuntu-backup.tar

这个 tar 包就是整个根文件系统的快照。拷到目标机器之后，先建一个目录用来放虚拟磁盘，然后导入：

mkdir D:\wsl\ubuntu wsl --import Ubuntu D:\wsl\ubuntu D:\backup\ubuntu-backup.tar --version 2

导入完成后用wsl -d Ubuntu进去。这里有个常见的坑：通过 import 方式装进来的发行版，默认登录用户是 root，不会走初始化流程，也不会问你要用户名密码。想改回普通用户，需要改注册表里的默认用户，或者干脆在/etc/wsl.conf里写死：

[user] default=yourname

写完保存，回到 PowerShell 执行wsl --shutdown再重进，用户就切过来了。

3.4 三条路线的对比与选择建议

我自己的习惯是先用一键，失败两次以上就立刻切离线，不要在一键上反复耗时间。因为一键失败通常是网络原因，重试十次还是同样的结果。

4. Ubuntu 首次进系统后的必经配置

装完只是开始，一个没配置过的 Ubuntu 用起来到处是别扭。这一章讲的是我每次装完新环境都会做的几件事，顺序基本固定。

4.1 系统更新、apt 换源与常用工具补齐

第一件事永远是更新：

sudo apt update && sudo apt upgrade -y

但默认的软件源在国外，国内访问经常慢到怀疑人生，几 KB 每秒是常态。所以更新之前先换源更划算。做法是备份原文件再替换：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's|archive.ubuntu.com|mirrors.example.edu.cn|g' /etc/apt/sources.list

新版本的 Ubuntu 用的是sources.list.d/ubuntu.sources这种 deb822 格式，改法和上面类似，把 URI 字段指向国内镜像站即可。换完之后apt update一般是几秒钟的事。

常用工具我一般一次性装齐：

sudo apt install -y build-essential git curl wget vim htop tree unzip zip net-tools

这里面build-essential是编译工具链，git和curl是基础设施，htop看系统状态比top舒服，tree看目录结构直观。装完之后git要配一下身份：

git config --global user.name "your_name" git config --global user.email "your@email.com"

提醒：换源之后如果apt update报签名错误，多半是源地址写错或者镜像站没同步完整。切回官方源验证一下，确认是源的问题再换另一个镜像站。

4.2 中文输入法与中文显示的处理

WSL 默认是纯命令行环境，本身不需要输入法。但如果你打算在里面装 GUI 应用、看中文文档、或者用 VS Code 的终端跑输出中文的脚本，中文显示就会出问题——表现为方块、乱码、或者宽度对不齐。

处理思路分两层。第一层是 locale 设置，检查当前值：

locale

如果输出里LANG是C或者POSIX，中文会显示异常。改成 UTF-8：

sudo apt install -y locales sudo locale-gen en_US.UTF-8 sudo update-locale LANG=en_US.UTF-8

第二层是字体。命令行里要想正常显示中文，需要一个带中文字形的等宽字体。可以装fonts-noto-cjk：

sudo apt install -y fonts-noto-cjk

如果你在 Windows Terminal 里用，字体其实由 Windows 侧决定，Ubuntu 里装不装影响不大；但如果你走的是 X Server 转发或者第三方终端，那就得装。至于图形界面的中文输入法，那是另一个话题——WSL 默认没有原生 GUI，装输入法之前得先把显示方案解决掉，复杂度明显高于命令行场景，我不建议新手一上来就折腾这个。

4.3 文件系统互通与路径映射的细节

这是 WSL 最有价值的能力之一，也是最容易踩坑的地方。Windows 的盘符在 WSL 里挂载在/mnt/下面，C 盘就是/mnt/c。反过来，Ubuntu 的文件在 Windows 里可以通过\\wsl$\Ubuntu\这个网络路径访问，在资源管理器地址栏敲这个就能打开。

但有两个坑必须说。第一个是前面提过的性能问题：代码项目一定要放在 Linux 侧的家目录里，比如/home/yourname/projects，不要放在/mnt/c/Users/...下面。原因是 WSL 2 访问 Windows 文件系统要经过一层 9P 协议转换，小文件多的场景能慢十倍以上。我见过有人把node_modules放在 Windows 侧，npm install跑了二十分钟。

第二个是权限和换行符。Windows 侧的文件默认权限是 777，而且行尾是 CRLF，直接拿去 Linux 里跑脚本会报bad interpreter这种诡异错误。解决办法一个是把项目放 Linux 侧，另一个是在项目里加.gitattributes统一换行符：

* text=auto eol=lf

或者配置 Git 全局处理：

git config --global core.autocrlf input

提醒：不要在 WSL 里用chmod去改/mnt/c下面的文件权限，改了也不会生效，还会让你困惑半天。这是设计如此，不是 bug。

4.4 内存、CPU 与磁盘的动态调节

WSL 2 默认会拿走最多一半的物理内存和全部逻辑核心。对台式机来说没问题，但笔记本上会导致 Windows 侧变卡。解决办法是在 Windows 用户目录下建一个.wslconfig文件：

[wsl2] memory=8GB processors=6 swap=4GB localhostForwarding=true

放的位置是C:\Users\你的用户名\.wslconfig，建完执行wsl --shutdown让它生效。内存给多少合适？我的经验是留出 4 GB 给 Windows 常驻，剩下的按七三分配，比如 32 GB 内存给 WSL 8 到 12 GB 比较舒服。

还有一个隐藏问题：磁盘文件只涨不缩。跑久了ext4.vhdx可能膨胀到几十 GB，即使里面实际只用了几 GB。清理方式是先用wsl --shutdown关掉，然后用磁盘管理工具压缩，或者直接在 PowerShell 里操作：

wsl --shutdown Optimize-VHD -Path "D:\wsl\ubuntu\ext4.vhdx" -Mode Full

注意Optimize-VHD需要 Hyper-V 模块，家庭版可能没有，那就用第三方分区工具处理。

5. 把开发环境真正跑起来：VS Code、Docker 与 GPU

基础环境配好之后，接下来是让它真正能干活。这一章是我日常使用频率最高的部分。

5.1 在 VS Code 里无缝使用 WSL

这是我最推荐的一个组合。装完 VS Code 和官方 WSL 扩展之后，你在 Ubuntu 终端里进入项目目录，敲一句：

code .

VS Code 就会以 WSL 模式打开这个目录。此时所有插件、终端、调试器都跑在 Linux 侧，文件路径也是 Linux 路径，但界面依然是 Windows 的原生窗口。这个体验比在 Windows 侧打开项目再连远程要顺畅得多。

装扩展的时候要注意区分：插件商店里有些扩展标了"Remote"标签，这些装在 WSL 侧；没标的装在 Windows 侧。你打开扩展面板时，装到哪一边取决于你当前窗口的模式，装错了会出现"命令找不到"的情况。我一般的原则是语言相关的（Python、Go、C++ 插件）装 WSL 侧，界面相关的（主题、图标）装 Windows 侧。

5.2 Docker 在 WSL 里的两种装法

Docker 有两种路子。第一种是装 Docker Desktop for Windows，然后在设置里勾选"使用 WSL 2 引擎"，它会自动把 Docker 上下文注入到你的 Ubuntu 里，你在 WSL 里敲docker ps就能用。这种方式省心，但 Docker Desktop 有商业授权限制，公司规模大的话要注意合规。

第二种是在 Ubuntu 里直接装 Docker Engine，完全绕开 Windows 侧：

sudo apt install -y ca-certificates curl gnupg curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker $USER

装完要重新登录一次让用户组生效。这种方式的好处是干净、没有额外授权问题，坏处是没有图形界面管理。我个人在个人机器上用第二种，公司环境看合规要求选第一种。

验证是否正常：

docker run --rm hello-world

看到输出里出现欢迎信息就说明通了。

注意：usermod -aG docker这一句如果不加-a，会把你的用户从其他所有附加组里踢出去，可能导致 sudo 都用不了。这个参数千万不能漏。

5.3 CUDA 与 GPU 直通的关键前提

搞 AI 的人最关心这个。好消息是 WSL 2 支持 GPU 直通，坏消息是有几个硬性前提。第一，必须是 WSL 2，WSL 1 完全不支持。第二，Windows 侧要装对应显卡厂商的最新驱动，注意是 Windows 驱动，不是 Linux 驱动——WSL 里的 CUDA 是复用 Windows 驱动通过虚拟化层转发的。第三，Ubuntu 里要装 CUDA Toolkit，但不要装 Linux 版显卡驱动，装了会冲突。

验证步骤是先装工具包：

sudo apt install -y nvidia-cuda-toolkit

然后运行：

nvidia-smi

如果能看到显卡型号、显存、驱动版本，说明通路已经打通。如果报"command not found"或者"No devices were found"，回头检查 Windows 侧的驱动版本是否够新。

这里我踩过一次坑：显卡驱动装太旧，nvidia-smi能跑但 CUDA 程序报版本不匹配。后来把 Windows 驱动升到最新，问题立刻消失。所以我建议装完 WSL 之后，顺手把显卡驱动更新到最新，这一步能省掉后面大量排查时间。

5.4 让终端接近 macOS 观感的字体与主题配置

最后聊聊颜值，虽然是次要的，但每天面对十几个小时的界面，舒服一点确实影响心情。接近 macOS 观感的关键其实不在主题配色，而在字体的字形设计和间距。

我的配置是这样的：字体用 JetBrains Mono 或者 Maple Mono，字号 12 到 13，行高 1.2，开启字体连字（ligatures）。配色用低饱和度的深色方案，避免纯黑背景配纯白文字，那种对比度太高，看久了眼睛疼。Ubuntu 侧的PS1提示符可以简化一下，把冗长的路径显示改成只显示当前目录名，配置写在~/.bashrc里：

export PS1='\[\e[32m\]\u@\h\[\e[0m\]:\[\e[34m\]\w\[\e[0m\]\$ '

想要更现代的体验可以上 zsh 加 oh-my-zsh，但说实话，如果你只是日常敲命令，bash 加上合理的提示符配置已经够用，装一大堆插件反而拖慢每次开终端的速度。

6. 常见故障速查与排查实录

前面讲的是顺路情况，这一章讲的是翻车现场。我把这些年遇到频率最高的问题整理成表，附上我的实际处理方式。

6.1 安装卡慢、下载中断与网络相关故障

wsl --install卡在下载阶段是最常见的问题，表现是进度条长时间不动，或者报超时错误。原因通常是发行版包体较大，而下载源在国外。处理方式有几个：换时间段重试（凌晨确实快一些）、用wsl --update单独更新内核（内核包小很多）、或者干脆走第 3 章说的离线导入。

还有一个情况是安装完成了但wsl命令本身很慢才响应，敲个命令要等两三秒。这通常和系统资源占用有关，检查一下是不是有安全软件在实时扫描 WSL 的虚拟磁盘文件。把 WSL 相关目录加入排除列表之后会明显改善。

6.2 SSH 连接不上与端口转发排查

WSL 里的 SSH 服务有个特点：它监听的端口在 Windows 侧是可以通过localhost直接访问的，微软做了自动转发。但很多人反馈连不上，原因一般有三个。第一，Ubuntu 里根本没装或没启动 SSH 服务：

sudo apt install -y openssh-server sudo service ssh start

第二，配置文件里PermitRootLogin或者PasswordAuthentication被禁掉了，查/etc/ssh/sshd_config。第三，端口冲突，Windows 侧已经有个程序占了 22 端口，这时候要改 WSL 里 SSH 的监听端口。

还有一种情况是你在 WSL 里跑了某个 Web 服务，浏览器访问localhost打不开。这时候先确认服务监听的是0.0.0.0而不是127.0.0.1，后者在 WSL 2 的虚拟化网络下可能转发不到。改监听地址一般就能解决。

6.3 中文乱码、解压乱码与编码相关问题

压缩包解压出来文件名全是乱码，这是从 Windows 打包、在 Linux 解压时的经典问题。根源是 Windows 上打包工具用了 GBK 编码写文件名，而 Linux 按 UTF-8 去读。处理方式是解压时指定编码，或者用能识别编码的工具。

比如处理 zip：

unzip -O gbk archive.zip -d output/

如果-O参数不支持（不同发行版的 unzip 版本有差异），可以先在 Windows 侧用支持 UTF-8 的打包工具重新压一次，这是更省事的做法。

终端里显示乱码则回到 4.2 节讲的 locale 和字体问题。两者容易混淆，判断方法是：用cat看文件内容乱码，是编码问题；用ls看文件名乱码，是文件名编码问题。

6.4 我踩过的几个非典型坑

说几个不那么常见但很折腾人的。第一个是时间不同步。笔记本休眠唤醒之后，WSL 里的时间可能和 Windows 差几个小时，导致 Git 提交时间错乱、HTTPS 证书校验失败。解决办法是同步一下：

sudo hwclock -s

第二个是wsl --shutdown之后网络断掉，重进恢复正常，这通常是 Windows 侧的网络驱动或者安全软件在切换网络时干扰了虚拟网卡，重启一次 Windows 比反复重启 WSL 有效。

第三个是文件句柄泄漏。长时间跑 Docker 容器之后，你会发现 WSL 占的内存越来越多，free -h显示缓存区巨大。这是 Linux 的正常行为，缓存会按需回收，不用手动清。但如果真到了影响 Windows 的地步，wsl --shutdown是最彻底的解法，代价是所有服务要重启。

第四个是关于在 WSL 里跑 Elasticsearch、Redis 这类带内存要求的服务。WSL 的默认内存上限可能会让它们启动失败，报max virtual memory areas vm.max_map_count is too low之类。处理方式是在/etc/sysctl.conf里加大限制，或者直接在.wslconfig里给 WSL 更多内存。

sudo sysctl -w vm.max_map_count=262144

这行只能临时生效，写进配置文件才能持久化。

提醒：每次修改.wslconfig或者/etc/wsl.conf，都必须执行wsl --shutdown再重新进入，配置才会重新加载。直接在运行的实例里改，看不到任何效果。

6.5 什么时候该推倒重来

最后分享一个判断经验：什么时候该修，什么时候该重装。我的标准是，如果问题涉及系统级的组件损坏（比如 apt 彻底坏掉、系统库被误删、locale 配置混乱到无法生成），重装一个干净发行版的成本远低于修复。因为 WSL 的发行版本质就是一个 tar 包加一个虚拟磁盘，删掉再导入只要几分钟。

备份方式也很简单，wsl --export定期导一次 tar 包，放在别的盘上。我一般两周导一次，体积几十 GB 但心里踏实。真出问题的时候，wsl --unregister干掉旧的，再wsl --import导回来，十分钟之内环境就恢复到导出时的状态，比现场排查省事得多。

这套 WSL 加 Ubuntu 的组合，我从最初的手忙脚乱到现在半小时能搭好一套完整开发环境，中间交了不少学费。最想说的是两点：一是把项目文件放在 Linux 侧的文件系统里，这一个习惯能解决一半以上的性能抱怨；二是提前配好.wslconfig和备份习惯，前者让你平时用得舒服，后者让你出事的时候不慌。剩下的，就是多用，命令敲熟了自然就有感觉了。