Win11下WSL2+Ubuntu配置、优化与避坑指南

简介：面向 Windows 11 开发者的 WSL2 与 Ubuntu 20.04 安装配置代码包，主要解决在非系统盘部署 Linux 子环境、初始化开发工作区等问题，适合需要在 Windows 下稳定使用 Linux 环境进行源码管理与软件包操作的软件工程师。压缩包共 3 个文件，包含 HTML 操作说明、inscode 配置脚本与 .gitignore 工程文件，整体仅 8KB，轻量且结构清晰。已有 118 人学习下载。内容紧扣安装指南的完整流程，涵盖 WSL 功能启用、PowerShell 命令设置默认版本、Ubuntu 发行版解压安装、非系统盘部署注意事项，以及文件操作、目录切换、权限管理等常用 bash 命令参考，并根据 .inscode 脚本化配置减少重复手工操作。借助这套代码包，可快速搭建可复用的 Linux 开发环境，为源码管理、代码编译与软件包管理提供落地方案，也可作为团队协作时环境一致性的统一基础模板。

1. WIN11 下的 WSL2+Ubuntu 到底是什么：先搞清它值不值得装

这标题看起来像一条装机教程，但真要在 WIN11 上用 WSL2+Ubuntu 跑项目代码，重点其实不在「装」这个动作上。WSL2 本质上是 Windows 托管的一台轻量虚拟机，它比传统虚拟化方案更省资源，启动速度和文件访问又比完整虚拟机更贴近本机，所以这些年成了 Windows 上跑 Linux 工具链的主流选择。它解决的痛点很具体：你想在 Windows 上编译一个 Linux 项目、跑一段 Python 脚本、起一个 Docker 容器，又不想再开一台虚拟机来回切换。装上这套环境后，Windows 终端里直接敲wsl就进入 Ubuntu，项目代码放在 Linux 文件系统里构建，性能和真机几乎没有差别。这篇文章就是沿着「前置检查 → 安装 → 初始化 → 资源调参 → 避坑」的顺序，把一条可直接复现的路径写清楚。适合两类人：一是新手，照着步骤能把环境搭起来；二是熟手，想确认自己的参数和目录放法有没有更好的选择。

2. 装机前的三件事：虚拟化开关、可选功能与 WSL 版本确认

Win11 上一条wsl --install确实能装完，但我一贯建议先分步做，因为后面出错的环节大概率不在这条安装命令本身。装 WSL2 的前置条件说白了只有三个：BIOS 里开了虚拟化、Windows 可选功能里有两个组件是启用的、WSL 内核与默认版本正确。少一个，后续全是黑匣子报错。

2.1 先查虚拟化：BIOS 没开，后面所有报错都是白折腾

先在任务管理器——性能——CPU 里找「虚拟化」字段，显示「已启用」就可以跳到下一节。如果显示「已禁用」，Windows 这边怎么操作都白费，因为 WSL2 依赖 Hyper-V 的虚拟机监控程序，CPU 虚拟化没打开，虚拟机平台根本起不来。

用管理员身份打开 PowerShell，执行下面这条命令可以确认固件层面的状态：

systeminfo | findstr /i "虚拟化"

输出如果是「已启用」就继续；如果提示固件中已禁用，重启进 BIOS，找 Intel Virtualization Technology 或 SVM Mode，改成 Enabled 后保存重启。这里有个容易被忽略的点：不少品牌机的 BIOS 默认关着虚拟化，而且菜单藏得比较深，建议直接搜主板型号加「虚拟化」三个字找路径。另外，Win11 家庭版同样支持 WSL2，网上「家庭版没有组策略就不能开」的说法是旧时代的经验，现在用命令或设置应用都能开，不用纠结版本。

2.2 用命令启用两个 Windows 功能：搞清wsl --install背后做了什么

最省事的做法是管理员 PowerShell 里执行：

wsl --install --no-distribution

这条命令会把「适用于 Linux 的 Windows 子系统」和「虚拟机平台」两个功能一次性打开，并补上 WSL 内核，最后提示重启。--no-distribution表示只装组件不装发行版，适合你想自己选 Ubuntu 版本的情况。如果机器网络环境比较差，或者你希望每一步都可控，就用下面这两条 dism 命令替代：

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

/all是把该功能的子功能一起启用，/norestart是暂时不重启，等两条都执行完再手动重启。重启之后，再确认一下内核是最新的：

wsl --update --web-download

--web-download会从网络上下载最新内核包，避免使用系统自带的旧版本。

2.3 三条命令确认 WSL2 状态：版本别停在 1

装完组件后，先用三条命令确认环境状态：

wsl --status wsl --version wsl -l -v

wsl --status会显示「默认版本」是 1 还是 2，我们要的是 2；wsl --version看的是 wsl.exe 自身的版本信息，如果这里输出异常，说明内核组件没装好；wsl -l -v列出已安装的发行版，VERSION 列必须是 2。若看到某个发行版停在 1，手动切过去：

wsl --set-default-version 2 wsl --set-version Ubuntu-22.04 2

第一条把后续新装发行版的默认版本设为 2，第二条把已装的指定发行版从 1 转成 2。转换过程需要一点时间，中途别关窗口。为什么必须用 2：WSL1 是系统调用翻译层，跑 Docker、systemd 这类依赖内核特性的东西会翻车；WSL2 是真正的 Linux 内核跑在轻量虚拟机里，项目代码的兼容性接近一台真实的 Ubuntu 服务器。

3. 装 Ubuntu 与初始化：版本选择、首次登录后要改的三处设置

前置检查做完，接下来就是装 Ubuntu。这个环节看起来只是选个发行版，但版本选错、systemd 没开、locale 没配，后面跑项目时都会以奇怪的方式暴露出来。

3.1 Ubuntu 版本怎么选：22.04 LTS 与 24.04 LTS 的取舍

先看在线可用的发行版列表：

wsl --list --online

输出里一般能看到 Ubuntu 主版本和具体 LTS 版本号。对大多数项目来说，我建议优先装 LTS，不要追最新非 LTS。22.04 和 24.04 之间怎么选，主要看项目依赖：

• 老项目、依赖预编译库多、构建脚本写死版本号的，选 22.04，它的 glibc 和默认 Python 3.10 兼容面更宽。
• 新项目、没有历史包袱、需要较新工具链的，选 24.04，内核和 GCC 版本都更新，跑 Rust、Go 这类新生态更舒服。

安装命令直接用发行版名：

wsl --install -d Ubuntu-22.04

如果提示找不到这个名字，就回到wsl --list --online看列表里的准确写法再执行。装完会自动打开 Ubuntu 窗口，开始初始化。

3.2 首次登录的初始化四件事：用户、更新、时区、中文编码

首次进入 Ubuntu 窗口，系统会要求你输入一个用户名和密码。这里注意三件事：用户名确认后不能再改，密码输入时屏幕不显示任何字符，别以为键盘坏了。这个用户后续是默认登录用户，尽量起一个好记的名字。

接着第一件事是把系统更新到最新：

sudo apt update && sudo apt full-upgrade -y

apt update是刷新软件包索引，full-upgrade比upgrade更彻底，它会处理依赖关系变化，把内核和核心库一起升级。项目依赖的构建链往往要求系统库版本不能太旧，这一步别省。

第二件事是时区。默认 UTC 会导致项目日志时间和 Windows 对不上，执行：

sudo dpkg-reconfigure tzdata

在弹出的交互界面里选你所在的城市即可。这个工具的好处是本地化，不用担心记错时区字符串。

第三件事是中文编码。如果项目日志打印中文、文件名带中文，默认的 locale 会显示成乱码：

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

locale-gen生成对应的语言环境，update-locale把它设为默认。改完退出终端重新进一次才生效。如果项目全是英文输出，这步可以跳过。

3.3 项目代码需要 systemd：用 /etc/wsl.conf 管理引导行为

WSL2 刚装好的 Ubuntu 默认不以 systemd 作为 init 进程，所以直接执行systemctl start ssh这类命令会报「System has not been booted with systemd」。现代 Ubuntu 的很多服务管理都依赖 systemd，项目代码里但凡有systemctl enable的步骤，这一条必须配置。

在 Ubuntu 里创建或编辑/etc/wsl.conf：

sudo vi /etc/wsl.conf

写入以下内容：

[boot] systemd=true [automount] enabled=true options="metadata,umask=22"

[boot] systemd=true开启 systemd，让 WSL2 的引导行为更接近真实 Ubuntu；[automount]控制 Windows 盘符在 Linux 下的挂载方式，metadata让 Windows 盘的权限位尽量能用，umask=22是给新建文件一个合理的默认权限。保存后回到 Windows 侧执行一次wsl --shutdown，再重新进入 Ubuntu，systemctl就能正常工作了。

3.4 建议先装这七个包：项目跑起来的通用底座

初始化阶段我一般会先装一套通用工具包，避免每个项目都要回头补：

sudo apt install -y build-essential git curl wget ca-certificates python3-pip htop

build-essential是编译工具链核心，包含 gcc、g++、make，几乎所有需要源码编译的包都依赖它；git用来拉项目代码；curl和wget负责下载；ca-certificates解决 HTTPS 证书校验问题，没有它一些源拉不下来；python3-pip是 Python 包管理器；htop用来观察负载和内存。这七个包是通用底座，不是银弹。项目如果基于 Node、Go 或 Rust，再按 README 装对应的运行时，不要一上来装一堆用不上的服务，后面维护成本高。

4. 项目代码跑得动的前提：.wslconfig 资源上限、磁盘位置与网络放行

环境装上只是第一步。真正让 WSL2 好用的是资源控制：默认情况下 WSL2 能吃掉宿主机大半内存，磁盘越撑越大，网络还受 NAT 限制。这三个问题全在 Windows 侧的配置文件里解决。

4.1 用 .wslconfig 定死资源上限：别让它和 Windows 抢内存

默认配置下，WSL2 最多可以占用宿主机 50% 左右的内存，而且宿主机内存压力大时并不一定会立刻回收。我有一次做编译，Windows 侧开了几个大程序，WSL 又占掉一大半内存，整机直接卡到鼠标都动不了。从那以后我养成了一个习惯：无论机器多大内存，都会在.wslconfig里把上限写死。

在 Win11 用户目录下新建.wslconfig文件。Windows 资源管理器默认不显示点开头的文件，用命令创建最稳：

notepad "$env:USERPROFILE\.wslconfig"

弹出记事本后写入：

[wsl2] memory=6GB processors=4 swap=2GB swapFile=D:\\wsl\\swap.vhdx networkingMode=mirrored nestedVirtualization=true

保存后回 PowerShell 执行：

wsl --shutdown

血泪经验：不wsl --shutdown的话，改多少次配置文件都不会生效，WSL2 只在启动时读一次.wslconfig。这里几个参数的意义如下：

如果机器内存只有 8GB，memory建议给 4GB 以内；16GB 机器给 6-8GB 比较合适。太大的swap没有意义，项目真需要大内存时，优先考虑加物理内存或改用远程开发机。

4.2 把发行版和磁盘挪出 C 盘：vhdx 空间回收

WSL2 的所有数据都存放在一个 vhdx 虚拟磁盘文件里，默认落在 C 盘用户目录的包路径下。这个文件会动态增长，但不会自动回收：apt 缓存、Docker 镜像、编译中间文件都会让它越变越大。C 盘本来就不宽裕的人，迟早会被它撑到报警。

把整个发行版迁到其他盘，在 Windows 侧执行：

wsl --manage Ubuntu-22.04 --move D:\wsl\ubuntu

--move要求发行版当前处于关机状态，所以先wsl --shutdown。迁移完成后，原来的 C 盘空间会释放，发行版数据整体搬到新位置。如果只是想压缩现有 vhdx，不需要挪盘，就执行：

wsl --shutdown wsl --manage Ubuntu-22.04 --compact

--compact会把 vhdx 里没有使用的空间回收掉。这个操作适合大版本升级后、Docker 镜像清理后、或者df -h看到根分区使用率虚高时做。注意 compact 只对关机状态的发行版有效，而且执行时间跟磁盘大小有关，别中途断电。

4.3 镜像网络与防火墙放行：让外部机器能访问 WSL 里的服务

默认 NAT 模式下，Windows 本机可以用 localhost 访问 WSL 里的服务，但局域网内其他设备访问不了。我一般直接把网络模式改成镜像网络：

[wsl2] networkingMode=mirrored

镜像模式下 WSL2 与 Windows 共享同一套 IP 和网络接口，端口监听行为更像真实服务器，外部设备通过 Windows 的 IP 就能直接访问到 WSL 里跑的服务。改完同样要wsl --shutdown。

外部要访问时，还需要在 Windows 防火墙放行对应端口：

New-NetFirewallRule -DisplayName "WSL Dev Server" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

LocalPort换成你的项目端口，DisplayName自己起一个能认出来的名字。最后确认服务本身监听了所有网卡，比如 Python 写一个临时服务：

python3 -m http.server 8080 --bind 0.0.0.0

只绑定 127.0.0.1 的服务，外部永远访问不了，镜像网络也救不了你。有个边界情况提醒一下：镜像网络在部分网卡驱动或安全软件环境下可能出现兼容问题，遇到访问异常，可以切回默认 NAT 模式，改用 Windows 端口转发规则解决，不要死磕这一个参数。

5. WSL2 安装到项目跑通的常见问题避坑：7 个踩坑记录

环境搭得多了就会发现，WSL2 的问题很少出在「装不上」，而是集中在启动、磁盘、网络这三类。这一章是把这些年项目的部署环境里踩过的坑按现象分个类，每条都是「现象 → 原因 → 解决」三件套，方便你直接对照。

5.1 启动与内核：三条最常见的启动时报错

第 1 条：wsl 启动报「请启用虚拟机平台 Windows 功能并确保在 BIOS 中启用虚拟化」，错误码 0x80370102。原因基本就两个：BIOS 里虚拟化被关了，或者 VirtualMachinePlatform 功能没真正启用。解决方法是先重启进 BIOS，确认 Intel Virtualization Technology 或 SVM Mode 是 Enabled，再用管理员 PowerShell 执行dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart，重启后再试。

第 2 条：Windows 更新后，wsl -l -v提示内核版本过低，或者 Ubuntu 启动后窗口一直卡住。原因是 WSL2 的内核由 Windows 侧提供，系统更新后旧内核和虚拟机平台不匹配。解决方式是执行wsl --update --web-download，把内核更新到最新版本。如果更新时网络异常，先wsl --shutdown再重试，多半是 vhdx 文件被占用导致的失败。

第 3 条：Ubuntu 里执行systemctl报「System has not been booted with systemd as init system」。原因是 WSL2 默认 init 进程不是 systemd，项目脚本里凡是用了systemctl enable的地方全会挂。解决方式就是 3.3 节里写的/etc/wsl.conf配置[boot] systemd=true，然后wsl --shutdown重进。检查是否生效，在 Ubuntu 里跑ps -p 1 -o comm=，输出systemd才算成功。

5.2 文件系统与磁盘：项目放错位置比参数调错更伤

第 1 条：把项目代码放在/mnt/d下，npm install 或 make 编译明显比 Linux 本机慢，IO 占用还高。原因是/mnt/d走的是 drvfs 文件系统，底层协议对海量小文件不友好，node_modules、build 目录这类动辄几万个小文件的操作会把性能拖垮。解决方式是把项目目录放到 Linux 侧的~/projects，数据、依赖、构建产物全放 Linux 侧。Windows 侧只做编辑，用 VS Code 的 Remote 方式打开 WSL 路径，不要用 Windows 路径直接构建。项目必须引用 Windows 盘的数据时，只放数据文件，别放代码和依赖。

第 2 条：C 盘空间越来越少，定位到ext4.vhdx体积巨大。原因是 vhdx 动态增长但不自动回收，apt 缓存、Docker 镜像、编译中间文件都会残留。解决方式是 4.2 节说的wsl --manage --compact，长期方案是把发行版--move到其他盘。我自己习惯每月做一次wsl --shutdown && wsl --manage Ubuntu-22.04 --compact，顺手清一下sudo apt autoremove。

第 3 条：忘记初装时设置的 Linux 密码。原因是密码输入时不显示字符，很容易记混。解决方式是在 PowerShell 里执行wsl -u root直接以 root 身份进入 Ubuntu，然后运行passwd 用户名重设密码，之后exit退出再正常登录。这里多提醒一句：root 身份虽然方便，但项目代码日常运行尽量用普通用户，权限边界一旦被磨平，后面排查问题会更难。

5.3 网络与服务：服务起不来或外部访问不了怎么办

第 1 条：WSL 里启动的 8080 服务，Windows 浏览器能打开，局域网其他设备连不上。原因是默认 NAT 模式下 WSL2 独立分配虚拟 IP，Windows 也没有主动做入站转发。解决方式是启用networkingMode=mirrored，把服务监听地址改成0.0.0.0，并且在 Windows 防火墙里放行对应端口。三条缺一不可，只做其中一两个都会失败。

第 2 条：SSH 服务起不来，sudo systemctl start ssh报找不到单元。原因是 WSL 里的 Ubuntu 默认不装 OpenSSH Server，很多人以为 systemd 开了 sshd 就能用。解决方式是：

sudo apt install -y openssh-server sudo systemctl enable --now ssh

装完后用sudo systemctl status ssh看状态。这里要额外提醒：如果项目只需要本机终端操作，sshd不是必装的，开了反而多一个暴露面。镜像网络模式下，外部设备一旦能访问，多一个监听端口就多一层风险。

第 3 条：WSL 服务启动时提示端口被占用，进程一启动就退出。原因是 Windows 侧的程序先监听了同一个端口，镜像网络下 WSL 与 Windows 共享网络栈，这种现象更常见。解决方式是在 PowerShell 里用netstat -ano | findstr :8080找到占用进程的 PID，再在任务管理器里确认是不是可以结束；如果是合法服务，就把项目端口改掉，别硬抢。

6. 从零到复现的最终检查单：五条命令确认环境可用

这套环境搭完，最怕的是「好像能跑，但不知道哪里不对」。我给自己定了一个检查流程，每换一台机器都先跑一遍这五条命令，全部通过才拉项目代码：

wsl --status wsl -l -v wsl -d Ubuntu-22.04 df -h / wsl -d Ubuntu-22.04 free -h wsl -d Ubuntu-22.04 nproc

逐条看输出：wsl --status里要有「默认版本：2」；wsl -l -v里 VERSION 列不能是 1；df -h /看根分区使用率，超过 90% 就该 compact；free -h看内存总量是否和.wslconfig里设的一致，不对就先wsl --shutdown再重进；nproc看 CPU 核数，和配置的processors对应上才算生效。这套检查单能把你从「玄学报错」里拉出来，任何一项异常，回去对照对应章节就能定位。

等检查单全部通过，剩下的就是常规 Linux 操作：在~/projects里克隆项目、按 README 装依赖、开始构建。我把整个安装流程压缩成一句话：先看虚拟化，再装组件，确认 WSL2 模式，初始化 Ubuntu 时开 systemd，最后用.wslconfig把资源边界定下来。

第一次在新电脑上部署这套环境时，我没设内存上限，忘了开 systemd，项目放在/mnt/c下跑了三天，每次构建都像在等一个黑匣子。后来把检查单跑一遍，五分钟就把根子问题全揪出来了：内存上限一设，构建不卡了；systemd 一开，服务脚本全活了；项目挪到~/projects，编译速度才真正回到 Linux 该有的水平。WSL2 不是装完就结束的工具，它值得你花十分钟把配置调到位，后面项目迭代会顺畅得多。希望帮到你。

本文还有配套的精品资源，点击获取