企业官网建设流程全解析

如果你在一台Windows电脑上需要一套完整的Linux环境，又不想开虚拟机把内存和CPU都分走一半，那WSL（Windows Subsystem for Linux）应该是目前最省心的选择。这篇文章聊的就是两件事：怎么用WSL把Ubuntu装进Windows，以及在完全没法访问外网的机器上，怎么用离线方式把同样的环境搭出来。两种场景我都会给出可以直接照着操作的步骤，如果你是第一次接触WSL，或者刚好卡在某一步报错上，这篇文章应该能帮你把路走通。

1. WSL这条路线到底解决什么问题

1.1 一个能互通文件、共享端口的"轻量Linux"

很多人第一次听说WSL时都会疑惑：我直接在Windows上装个虚拟机不也能跑Ubuntu吗？确实能，但虚拟机的问题是太重了。一个虚拟机要分配固定的内存、独立的磁盘空间，启动要等几十秒，文件在宿主机和虚拟机之间来回拷还麻烦。WSL的思路完全不同：它不是一个完整的虚拟机，而是Windows系统内置的一个Linux兼容层，或者说一个轻量级的Linux运行环境。

在WSL里，你可以直接使用Ubuntu的终端、包管理器、命令行工具、脚本，甚至跑Docker容器。和虚拟机相比，它最大的优势是文件系统互通——你在Windows桌面上建一个文件夹，WSL里直接就能访问；反过来，你如果在WSL里装了某个工具处理了一批文件，结果也存在Windows下可以看见的路径里。这种融合体验让很多日常开发工作变得非常顺畅。

我日常用WSL的场景大概是这样的：在Windows侧打开某编辑器或代码客户端，终端环境则完全切到Ubuntu里操作，代码文件本身又放在Windows文件系统中。这样两边工具各占所长，不用在系统之间来回切换。

1.2 WSL1与WSL2的差异，以及选择哪种

现在的WSL系统已经默认是WSL2了。WSL2和最初版本的WSL 1差距很大：WSL 1是通过API翻译层把Linux系统调用转成Windows系统调用来实现，所以启动极快、跟Windows文件系统的互相访问表现更好，但在真正的内核兼容性上有限制。WSL 2则是在一个轻量级虚拟机里运行了一个完整的Linux内核，系统调用完全原生，绝大多数Linux软件都可以直接跑，性能也更接近真实物理机。

两者怎么选？如果你是老机器、性能紧张，或者依赖跨文件系统的读写频繁操作，WSL 1在某些场合反而更快。但绝大多数项目，尤其是要跑Docker、要编译C/C++、要用到一些依赖内核特性的工具，建议直接使用WSL 2。WSL 2目前已经是默认配置，除非你手动切过，否则不用纠结这个问题。

你在了一些需要图形界面工具的场景下，WSL 2也能通过内置的WSLg功能把Linux图形程序窗口显示到Windows桌面上，不需要额外安装X服务器。这个后面实际操作时我会顺带提到。

2. 装之前先确认三件事：版本、虚拟化和磁盘

2.1 系统版本要求

WSL并不是所有Windows版本都支持得一样好。最省心的是Windows 11，以及较新版本的Windows 10系统，这些系统上WSL的支持已经是标配，一个wsl --install就能完成大部分工作。

如果你的Windows版本太老（比如还在早期版本的Win10 1803之前的版本），WSL安装方式会比较手工，需要去手动开启功能并下载内核更新包，而且功能上也会有所缺失。建议安装前先在Windows终端里跑一下系统版本信息确认，如果你的系统长期处于自动更新状态，版本一般不会是大问题。

我见过一些办公电脑是单位IT部门锁定了更新策略的，版本很老。这种机器如果还想用WSL，建议走本文第4节的离线安装路线，反而更可控。

2.2 虚拟化技术是否开启

WSL2依赖Windows的虚拟化功能（Virtual Machine Platform），而这项功能又依赖CPU虚拟化技术（Intel VT-x / AMD-V）。所以安装WSL2之前，最容易被忽略的一步就是：确认BIOS里虚拟化开关已经打开。

怎么快速确认？在Windows任务管理器里切到"性能"标签页，如果你看到下方有一栏标注"虚拟化：已启用"，那就没问题。如果显示"已禁用"，你需要重启电脑，开机时进BIOS设置界面（不同品牌按键不同，常见是F2或DEL），找到类似"Intel Virtualization Technology"或"SVM Mode"的选项并开启。

这个步骤经常被跳过，导致后续安装时出现0x80370102这类报错。我在第6节会专门讲怎么排查。

2.3 管理员权限与磁盘空间

安装WSL需要管理员权限。具体操作方式很简单，打开开始菜单，输入"终端"或"PowerShell"，在搜索结果上右键，选择"以管理员身份运行"，再执行后续的安装命令。

再一个是磁盘空间。一个Ubuntu发行版的根文件系统大概需要2到4GB空间，加上你后续安装各种软件包、代码仓库缓存，预留20GB以上会比较从容。如果C盘空间紧张，WSL也支持把发行版安装到指定磁盘分区，甚至可以直接放在D盘、E盘。这个我在离线导入那一节会详细操作。

另外提醒一下：如果你的电脑使用了BitLocker加密磁盘，或者开启了设备加密功能，WSL的虚拟磁盘文件默认情况下也能正常工作，不需要额外配置，只是在性能上会有一些影响，但这个基本无感知。

3. 在线安装：一条命令走完的标准流程

3.1 开启Windows功能并安装Ubuntu

在线安装的方式是我在给普通开发者推荐时的首选。前提是你的电脑能正常访问外网，并且Windows版本比较新。整个过程不需要你在Windows功能界面里勾来勾去，终端里敲两条命令就完成了。

在管理员身份的终端里依次执行：

wsl --install -d Ubuntu

这条命令会自动完成以下几件事：启用“适用于Linux的Windows子系统”功能、启用“虚拟机平台”功能、下载并安装WSL2内核、下载并安装Ubuntu发行版。整个过程需要保持网络畅通，下载时间看你网速，一般几分钟到十几分钟。

如果执行后发现系统提示"无法识别的命令"，说明你的Windows版本比较旧或WSL组件缺失，可以先手动启用旧功能：

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

执行完成后重启系统，再执行wsl --install -d Ubuntu。

这里有一个值得留意的细节：wsl --install默认安装的发行版不一定是Ubuntu，可能是系统商店当前主推的某个发行版。所以我在命令后面显式加了-d Ubuntu，避免装出来一个不是你想要的Linux发行版。

3.2 首次启动与账号初始化

安装完成后，开始菜单里会出现Ubuntu的入口，或者在终端里直接输入wsl回车，就会进入初始化流程。第一次启动Ubuntu时，系统会提示你创建一个Linux用户名和密码。

这个用户名和你的Windows用户名完全独立，需要注意：它默认会是一个普通权限用户，真正的管理员是root账号，sudo可以用来临时提权。密码输入时屏幕上不会显示任何字符，这属于正常现象，不是键盘出了问题，我第一次用Linux时在这个地方还困惑过。

账号创建完之后，你就进入了一个完整的Ubuntu Shell环境。可以跑：

cat /etc/os-release

看看发行版具体版本号。能看到版本信息，说明这个Ubuntu基本是可用的。

3.3 验证安装结果

安装完成的下一步，建议先确认一下当前的WSL版本和运行模式。

在Windows终端里执行：

wsl -l -v

输出结果里会列出已安装的发行版，以及运行模式，正常情况下应该是VERSION 2。如果显示的是VERSION 1，说明没有使用WSL2，可以执行：

wsl --set-version Ubuntu 2

主动把它切换过来。切换过程可能需要一点时间，终端会显示转换进度。

我自己在实践中的习惯是，新装的系统先在WSL里把基础工具装上，比如curl、git、build-essential等：

sudo apt update && sudo apt upgrade -y sudo apt install -y curl git build-essential

这样后续大多数开发依赖就有了。

4. 离线安装：两种不依赖外部网络的完整路径

4.1 离线场景是怎么出现的

我为什么要专门写离线方式，因为实际工作里遇到这种情况的机器比想象中多。单位的内网开发服务器、涉密机、或者某些实验室的机器，虽然能上网或用内部网络，但无法访问到系统商店和外部下载服务器。这时候你在线执行wsl --install，多数情况下会卡在下载阶段，然后给你一个网络错误的提示。

离线安装的核心思路只有两个字：搬运。让一台有外网访问权限的普通电脑，把发行版和组件下载好、导出成文件，再通过U盘或内网传输复制到目标机器上。目标机器全程不需要访问外网。

4.2 路线一：用tar包迁移已有发行版

这是我最推荐的离线安装方式，兼容性最好，中间步骤少，而且可以顺带把已经配置好的环境整个迁过去。

第一步，在一台已经装好WSL和Ubuntu的联网电脑上，打开终端执行导出命令：

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

导出过程会把整个Ubuntu文件系统打包成一个tar文件，时间取决于你的环境大小。默认装上没装多少软件的话，大概2到4GB，压缩后的tar文件会小一些。

然后把tar文件拷贝到目标离线电脑上（U盘、内网共享都可以），在目标电脑上执行导入：

wsl --import UbuntuOffline D:\WSL\UbuntuOffline D:\ubuntu-offline.tar --version 2

这里第二个参数D:\WSL\UbuntuOffline是安装路径，你可以把它放到空间充足的任意分区；第三个参数是tar文件的完整路径。导入完成后，用这条命令检查：

wsl -l -v

如果看到UbuntuOffline的VERSION是2，导入就成功了。进入系统：

wsl -d UbuntuOffline

4.3 离线安装后必须处理的两个细节

使用tar包方式导入的发行版有一个很典型的"后遗症"：默认会以root用户登录，因为wsl --import导入的是文件系统快照，原机器的默认用户配置并不会被记录下来。如果需要恢复成自定义普通用户，可以在导入后的Ubuntu系统里执行：

echo -e "[user]\ndefault=你的用户名" >> /etc/wsl.conf

改完在Windows侧执行wsl --shutdown再重进就生效了。

另外，如果这台离线机器本身从来没过WSL基础组件，wsl命令都不存在的，那第一步要先准备好WSL本身的离线组件。有两个文件需要注意：一个是WSL2的内核更新包（对应安装包形如wsl_update_x64.msi），另一个是WSL应用本身的安装包。内核更新包可以在联网机器上找官方渠道下载后拷过去，双击安装即可。WSL应用如果是新版系统通常已内置命令，但有些精简版或更新受限的系统还是需要手动安装。

为了避免你踩我踩过的坑，我建议在联网电脑上准备离线物料时，一次性把这几类文件都备好：

4.4 路线二：手动安装发行版离线安装包

另外一种离线方案是直接离线安装一个全新的Ubuntu发行版，不依赖旧机器的导出镜像。这种方法适合那些没有任何现成WSL环境的机器，且你希望从零开始配置。

在联网电脑上，从系统的软件商店页面获取Ubuntu的安装包文件。这类文件通常是.appx或.msixbundle格式，下载后会得到一个安装包文件。把这个打包文件复制到离线机器上，用管理员身份的PowerShell执行：

Add-AppxPackage -Path "C:\path\to\Ubuntu.appx"

安装完成后，开始菜单里就会出现Ubuntu图标。如果提示需要安装依赖，可能还需要一起准备一个VCLibs依赖包，一并拷过去安装。

这个方案的缺点是：Ubuntu发布的新版本如果更新了包依赖，可能需要带上更多附属文件；而且无法像tar包方案那样保留已有环境和配置。我的建议是优先试tar包方案，亲手操作过之后你会觉得它更像"把一个已经配置好的工作区打包带走"。

5. 切换到日常使用前需要补齐的几块拼图

5.1 软件源的问题：离线机器尤其要注意

装完Ubuntu后的第一道坎，往往是apt update慢或者失败。在线环境还好，顶多是慢一点；离线环境则完全无法使用外部源。这里的解决办法分两种情况。

如果你在离线环境里还需要通过apt安装软件包，需要提前在联网机器上下载好.deb安装包，拷进离线机器后用dpkg -i手动安装。例如你要装git，就到联网机器的Ubuntu里执行：

apt download git apt download git-man

然后把下载的.deb文件拷贝过去，执行：

sudo dpkg -i *.deb

如果提示依赖缺失，就再回到联网机器上把这些依赖包也导出来。这个过程比较原始，但对于内网隔离环境来说是标准操作。

如果在线环境中使用，建议顺手把系统的软件源切换到国内访问速度更快的镜像站。修改方式是在WSL Ubuntu里编辑：

sudo sed -i 's/archive.ubuntu.com/mirrors.ustc.edu.cn/g' /etc/apt/sources.list

这里镜像站地址可以根据你网络实测效果更换。测试连通性时，不建议只看"能ping通"，更可靠的是实际跑一下sudo apt update看有没有报错。

5.2 文件互访与路径习惯

WSL和Windows之间的文件互访有两个方向。在Ubuntu里访问Windows文件系统，路径映射类似这样：

/mnt/c/Users/你的Windows用户名/Desktop

可以看到Windows的C盘被挂载到了/mnt/c。反过来，在Windows里访问WSL内部文件系统，可以直接在资源管理器地址栏输入\\wsl$\Ubuntu，或者进到某个发行版对应的路径下。

这里有一个实践建议：日常项目代码放在Windows侧文件系统，然后在WSL里通过/mnt/c访问。这样做的好处是，就算WSL重装、发行版删了，代码文件也都还在Windows侧，不会跟着WSL环境一起消失。

不过要注意跨文件系统的读写性能差异。如果你的项目包含大量小文件（比如某些前端依赖的node_modules目录、Git仓库），放在Windows侧文件系统时，在WSL里跑编译安装可能会明显慢。这种情况可以把项目放到WSL内部文件系统（也就是wsl进入后所在的Linux文件系统里），速度会快很多。两边如何取舍，取决于你对"数据安全"和"性能"哪个优先级更高。

5.3 systemd与Docker场景

新版WSL已经支持systemd了，这对于很多需要跑系统服务的开发者来说是重大利好。开启方式是编辑/etc/wsl.conf：

[boot] systemd=true

改完执行wsl --shutdown重启发行版，然后就可以用systemctl了。

如果你需要在WSL里用Docker，也更推荐这种整合方式：在Windows侧安装Docker Desktop，并设置其使用WSL2后端，这样Docker的Linux容器实际上是跑在WSL里的，性能损耗很小。我的项目里通常不会在WSL内直接安装Docker引擎，因为Docker Desktop的WSL2集成度更好、资源管理更清晰。

6. 高频报错的排查顺序与备忘

6.1 步骤对了还是报错：先看虚拟化和版本

排在第一位的高频报错，是安装或启动WSL时报0x80370102。遇到这个错误码，我的排查顺序很固定：先查Windows功能是否已启用，再查BIOS虚拟化开关，最后查发行版版本。

systeminfo | find "虚拟化"

这条命令可以直接看到虚拟化状态。如果显示"已启用"但仍报错，那就进BIOS确认Intel VT-x或AMD SVM是否真的打开了。有些品牌的机器默认开启，有些则需要在BIOS里将虚拟化设为"Enabled"后重启。

另一个常见的启动报错是WSL_E_DISTRO_NOT_FOUND，通常是发行版没有正确安装，或者是Windows系统没有运行在支持WSL2的版本上。同样先确认版本，再考虑重装。

6.2 wsl命令本身出了问题的处理

新版的WSL被作为一个独立应用分发了，当系统商店组件出问题时，可能wsl命令还在，但是执行任何操作都提示WSL is not installed。我一直推荐的反直觉做法是：先执行wsl --update看能不能自我修复，而不是急着去重新启用Windows功能。这个命令会把WSL组件更新到最新版。

如果wsl --update因为网络原因（在离线机器上）失效，那前面说的离线内核更新包就派上用场了，手动安装后继续。

还有一点很容易被忽略：如果你用过组策略锁定了系统商店的自动更新，那么WSL的核心组件版本可能一直停留在旧版，这会导致某些新特性启用了但报错。离线环境下优先保证核心版本足够新，再谈具体发行版。

6.3 导入的发行版无法启动或默认用户不对

用wsl --import导入发行版之后启动报错的，在我接触的项目里，最常见的原因是导入时指定的安装路径中包含中文、特殊符号或者权限受控目录。比如直接导入到C:\Users\用户名\Documents\My Linux这类路径，有些系统环境下就会出问题。我的经验是：尽量使用纯英文、无空格的路径，比如D:\WSL\Ubuntu。

导入后如果系统启动了但在登录界面提示root无法登录、或者你创建了普通用户但看不到，大概率是/etc/wsl.conf里面没有配置默认用户，或者是之前导出的环境里残留了/etc/wsl.conf配置。直接用wsl -d 发行版 -u root进入，修改配置即可。

最后一个常见问题：导入的发行版显示VERSION为1，如果你需要WSL2功能（比如Docker），要执行：

wsl --set-version 发行版名 2

如果转换过程提示"虚拟化平台组件需要更新"，那就一定是内核组件版本太老，按第6.2节处理。

写到这里，整个WSL安装的在线和离线路径算是说透了。如果你问我个人项目里最大的体会是什么，我会说：离线安装的关键不是命令本身，而是提前想清楚要把哪些物料带过去。一次环境迁移把基础发行版、内核包、依赖包都备齐，比到了现场手忙脚乱找文件要省事得多。希望这篇能帮你在Windows和Ubuntu之间搭一座稳当的桥。