WSL 2 从安装到 Shell 实战：Windows 下打造原生 Linux 开发环境

很多玩Windows的朋友第一次接触到WSL这个词，第一反应都是：这玩意到底有什么用？我直接装个虚拟机不香吗？等你真的在公司电脑上试着用WSL跑过一次Linux命令、在WSL里装过CUDA跑过一次深度学习、或者因为项目需要不得不写shell脚本时，你就会发现——WSL这个微软亲儿子，确实能在Windows上用shell用出接近原生Linux的体验。这篇博文我从安装到排坑，把WSL和shell相关的实操经验一次讲透，适合刚想入门的开发新手，也适合准备把WSL迁移到正式工作环境的进阶玩家。

1. 项目核心思路：为什么选择WSL而不是虚拟机

1.1 WSL到底解决了什么问题

先说说我在实际项目里遇到的一个典型场景。领导丢过来一个需求：把一套原本跑在Linux服务器上的数据处理脚本，在本地Windows环境里调试好。你一打开项目文档，满屏的 grep、awk、sed，这些命令在PowerShell里要么语法不对，要么功能不全。这时候你有三个选择：装虚拟机、换Linux系统、用WSL。

装虚拟机的问题在于资源开销太大。我试过用VMware跑一个Ubuntu，开机就占2GB内存，磁盘还得单独分配几十GB，日常开发时来回切换窗口很割裂。换Linux系统更不现实，公司内部各种办公软件、OA系统都绑定Windows环境。WSL则完全不同——它不是一个完整的虚拟机，而是微软实现的一个兼容层，直接在Windows内核之上运行一个真实的Linux用户态环境。你不需要承担虚拟机那套硬件模拟开销，启动一个WSL发行版基本在几秒内完成，内存占用也就几百兆。

1.2 WSL 1和WSL 2怎么选

WSL目前主流的版本是WSL 2，它相比WSL 1最大的变化是使用了一个轻量级虚拟机（基于Hyper-V技术），内核是真正的Linux内核。WSL 1则走的是系统调用翻译的路线，把Linux的系统调用转换成Windows的系统调用。

在实际使用中，WSL 2的兼容性明显更好。比如你用 docker、apt 安装某些依赖、甚至编译Linux内核模块，WSL 1大概率会碰到兼容性问题。WSL 2对绝大多数Linux软件的兼容度已经达到"能跑就行"的水平。我个人的建议是：新用户直接装WSL 2，不要犹豫。

注意：WSL 2需要开启Windows的虚拟机平台功能。如果你的电脑不支持虚拟化（比如某些老旧的CPU，或者BIOS里关闭了VT-x），WSL 2可能无法正常运行。可以先去BIOS里确认虚拟化是否开启。

1.3 适合谁来学

如果你属于下面这几类人，这篇文章的实操内容会对你帮助不小：

• 前端或后端开发，需要用到Linux命令行工具链（比如 grep、sed、git、node），但又不想放弃Windows桌面。
• 机器学习或数据科学从业者，需要在Windows电脑上配置CUDA、跑PyTorch/TensorFlow，WSL 2是目前Windows下最接近Linux训练环境的选择。
• 运维或测试人员，需要在本机写shell脚本、模拟Linux服务器环境做验证。
• 学生党，学校课程要求用Linux环境跑实验，但电脑配置一般，跑虚拟机太卡。

2. 实操准备：Windows环境检查与基础设置

2.1 确认系统版本

在开始安装之前，先确认你的Windows版本支持WSL。当前主流的Windows 10（版本号2004及以上）和Windows 11都支持WSL 2。查看方法很简单：按 Win + R，输入 winver，回车就能看到系统版本号。

如果你还在用Windows 7，那很遗憾，WSL官方不支持，别折腾了，老老实实装虚拟机或者换系统。Windows Server 2019及以上版本也支持WSL，我在一台Server 2019上成功装过，但步骤比桌面版稍微繁琐一些，需要手动启用几个Windows功能。

2.2 启用必要的Windows功能

在安装WSL之前，有两个Windows功能需要确认已经开启。打开PowerShell（管理员身份），输入：

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

第一条命令启用“适用于Linux的Windows子系统”，第二条启用“虚拟机平台”。这两条命令执行完后，系统大概率会提示重启，建议重启后再继续后续操作。

如果你在PowerShell里执行命令时提示“无法识别 dism.exe”，说明PowerShell的执行路径有问题，可以用管理员身份打开CMD再试。另外，执行前最好关闭所有正在运行的软件，避免文件占用导致操作失败。

2.3 PowerShell和终端设置

Windows 11自带的Windows Terminal是目前体验最好的终端工具，建议直接安装。Windows 10用户也可以从微软商店搜索“Windows Terminal”免费安装。装好之后，把默认终端设置为Windows Terminal，后续所有shell操作都在这个环境里完成。

打开Windows Terminal，按 Ctrl + , 进入设置界面，在“默认终端应用程序”里选择“Windows Terminal”，然后把默认配置文件改成你之后要安装的Ubuntu（这个要装完WSL后才会出现在下拉列表里）。这个设置的好处是：以后打开终端，直接就是Linux shell环境，不用每次手动切换。

3. 核心安装步骤：一条命令装好WSL和Ubuntu

3.1 最简单的安装方式

WSL的最新版本支持一条命令直接安装默认发行版。用管理员身份打开PowerShell或Windows Terminal，执行：

powershell复制wsl --install

这条命令会自动完成以下操作：启用WSL功能、启用虚拟机平台、下载并安装WSL 2内核、安装Ubuntu（默认版本）。整个过程无需手动干预，适合不想折腾的新手。装完以后重启系统，首次启动Ubuntu时会提示你设置用户名和密码。

但这里有个非常常见的坑：很多人执行这条命令后，系统卡在“正在下载”的阶段，或者长时间没有进度。这就是热搜词里“wsl --install 太慢”的来源。原因一般是网络问题，微软商店的下载服务器在国内访问不稳定。解决办法有几个：

1. 手动指定发行版：先查看可用的发行版，执行 wsl --list --online，然后手动安装：

powershell复制wsl --install -d Ubuntu-22.04

2. 使用离线安装包：去微软官网手动下载WSL 2内核更新包和对应的Linux发行版Appx包（比如Ubuntu的 .appx 文件），然后双击安装。这个方法在网络状况差的时候最有效。

3. 检查网络配置：如果你开了系统代理，WSL的下载流量可能不经过代理，反而导致连接超时。可以临时关掉代理再试。

3.2 给WSL安装多一个发行版

WSL支持同时安装多个Linux发行版，比如你既想要Ubuntu，又想试一下Kali。用下面的命令查看当前已安装的发行版：

powershell复制wsl --list --verbose

安装Kali：

powershell复制wsl --install -d Kali-Linux

多个发行版之间相互独立，启动时用 -d 参数指定：

powershell复制wsl -d Ubuntu-22.04
wsl -d Kali-Linux

我平时会用Ubuntu做日常开发，Kali只拿来跑一些安全工具（比如binwalk分析固件），两个发行版互不干扰，挺舒服。要说有什么需要注意的，就是硬盘空间会多占一些，每个发行版至少2GB起步。

3.3 设置默认发行版和默认用户

如果你装了多个发行版，可以设置一个默认的，这样每次打开WSL终端就直接进入这个系统：

powershell复制wsl --set-default Ubuntu-22.04

如果你在Ubuntu里配置了多个用户（比如root和其他用户），想设置默认登录用户，可以编辑 /etc/wsl.conf，添加：

ini复制[user]
default=你的用户名

保存后退出WSL，执行 wsl --shutdown 重启WSL，再进去就生效了。这个方法比网上流传的 ubuntu config --default-user root 靠谱得多，也兼容新版WSL。

4. Shell基础：在Windows里高效使用Linux命令

4.1 第一次进入Shell环境

当你安装并启动WSL后，会看到一个类似这样的界面：

bash复制yourname@DESKTOP-XXXX:~$

这就是Linux shell的交互环境。默认的shell是Bash，这是Linux中最普及的shell之一。你在提示符后输入命令，敲回车就会执行。像 ls（列出文件）、cd（切换目录）、pwd（显示当前路径）、cat（查看文件内容）这些基础命令，几乎天天都要用到。

刚开始接触shell的朋友，最不习惯的一点是：怎么没有图形界面？其实shell就是一个纯粹的文本交互界面，你要做的所有事情都是通过敲命令来完成的。这恰恰是它高效的地方——你可以把一系列操作写成一个脚本，一键执行，不用像图形界面那样一步步点鼠标。

比如你想统计一个日志文件里出现“error”的次数，在shell里一条命令就搞定：

bash复制grep -c "error" app.log

在Windows的资源管理器里，你至少得打开文件、用编辑器的查找功能、数清楚数量，效率完全没得比。

4.2 文件和目录操作与Windows的差异

在Windows上，路径分隔符是反斜杠 \，比如 C:\Users\yourname\Desktop。在Linux shell里，路径分隔符是正斜杠 /，而且没有盘符的概念，一切文件都挂在根目录 / 下面。

WSL里访问Windows文件系统也很有意思。你在WSL里面可以看到Windows的所有盘符挂在 /mnt 下面：

bash复制ls /mnt/c/Users/yourname/Desktop

这个 /mnt/c 就是Windows的C盘。反过来，在Windows的资源管理器地址栏输入 \\wsl$\Ubuntu-22.04\home\yourname，就能打开WSL里的Linux文件目录。两边文件互通，这是WSL比虚拟机好用太多的地方。

4.3 Shell脚本入门：写一个自己的脚本

shell除了交互式执行命令，更重要的一种用法是写脚本。一个shell脚本就是一个包含多条命令的文本文件，可以一次执行。脚本文件的后缀通常是 .sh，其实后缀不影响执行，但建议加上方便识别。

写一个简单的脚本，自动备份某个目录下的文件。新建一个文件 backup.sh：

bash复制#!/bin/bash
# 这是一个备份脚本示例

backup_dir="/home/yourname/backup"
source_dir="/home/yourname/documents"

# 创建备份目录（如果不存在）
mkdir -p "$backup_dir"

# 用当前时间作为备份文件名
timestamp=$(date +"%Y%m%d_%H%M%S")
backup_file="$backup_dir/documents_$timestamp.tar.gz"

# 打包压缩
tar -czf "$backup_file" "$source_dir"

# 输出结果
echo "备份完成：$backup_file"

保存后，给脚本加上执行权限并运行：

bash复制chmod +x backup.sh
./backup.sh

这里补充几个新手容易踩的坑：

1. #!/bin/bash 这一行叫shebang，用来告诉系统用哪个解释器执行这个脚本。如果你用的是其他shell（比如zsh），就写 #!/bin/zsh。
2. 脚本里用到的变量，建议都用双引号包起来，防止文件路径里有空格时被拆分成多个参数。
3. chmod +x 必须执行，否则直接 ./backup.sh 会提示“Permission denied”。

4.4 常用Shell命令速查表

我整理了一份日常使用频率最高的命令清单，很适合放在手边查：

5. 进阶配置：目录迁移、CUDA和远程开发

5.1 WSL目录迁移：C盘不够用怎么办

WSL的发行版默认安装在C盘，位置在 C:\Users\你的用户名\AppData\Local\Packages\。用一段时间后你会发现C盘空间越来越小——因为WSL的虚拟磁盘文件（ext4.vhdx）保存了Linux里面的所有文件，动辄十几GB很常见。

把WSL目录迁移到D盘，网上流传的方法很多，我实测最稳定的方法是导出再导入：

bash复制# 以管理员身份打开PowerShell
# 1. 停止WSL
wsl --shutdown

# 2. 查看你要迁移的发行版名称
wsl --list --verbose

# 3. 导出发行版到备份文件
wsl --export Ubuntu-22.04 D:\wsl_backup\ubuntu.tar

# 4. 注销原来的发行版（不会删除备份文件）
wsl --unregister Ubuntu-22.04

# 5. 从备份文件导入到新目录
wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl_backup\ubuntu.tar --version 2

# 6. 启动确认
wsl -d Ubuntu-22.04

这里有一个容易忽略的点：用 --import 导入的新发行版，默认登录用户是root，而不是你之前创建的那个普通用户。想要切回原来的用户，编辑 /etc/wsl.conf 加上刚才讲的 [user] 配置即可。

另外，导入后你可能会发现原来在Windows里通过 \\wsl$ 访问Linux文件的方式变了，需要重新用资源管理器访问一次新的路径。

注意：执行 --unregister 会删除当前发行版的所有Linux内部文件，包括你安装的软件和保存的数据，所以务必先完成导出备份这一步。别问我怎么知道的，有些人就是手一抖直接输入了。

5.2 WSL里安装CUDA：打造本地深度学习环境

如果你需要在Windows下跑深度学习，WSL 2是一个不错的选择。相比原生Windows版本，WSL里的CUDA环境更接近Linux服务器，代码迁移到服务器上跑基本不用改。

前提条件有两个：

• 你的NVIDIA显卡驱动版本要比较新，建议直接用最新的Game Ready驱动或Studio驱动。
• Windows侧不需要安装完整的CUDA Toolkit，驱动里自带的支持就够用了。

进入WSL，安装CUDA Toolkit：

bash复制# 以Ubuntu 22.04为例，先更新包索引
sudo apt update

# 添加NVIDIA CUDA仓库（具体命令以NVIDIA官网为准）
# 下载并安装CUDA Toolkit的deb包

# 安装完成后，验证CUDA是否可用
nvidia-smi

如果执行 nvidia-smi 能正确显示显卡信息，说明CUDA环境基本就绪。接着安装PyTorch：

bash复制pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

在实际测试中，WSL 2里的CUDA性能损失很小，GPU利用率能维持在较高水平。我曾经在一个用PyTorch训练图像分类模型的场景里对比过原生Linux和WSL，训练速度几乎没有差别。

5.3 用PyCharm连接WSL：Windows下写代码，Linux环境里运行

很多Web开发的场景，项目依赖Linux环境的某些特性（比如 node-sass 编译时需要Python和make，或者项目里直接调用Linux的系统命令），用PyCharm连接WSL的开发模式就能很好地解决。

在PyCharm的设置里，找到“Project Interpreter”，选择“Add Interpreter”，然后选择“WSL”。PyCharm会自动检测到你已安装的WSL发行版，并把项目运行环境切换到Linux里。配置完成后，你在PyCharm里写代码，实际运行、调试都是在WSL的Linux环境里执行的，两边文件自动同步。

这个模式最大的好处是：你无需在Windows和Linux之间来回切换，还是熟悉的IDE界面，但代码运行环境完全Linux化。我自己用下来，比在虚拟机里装Linux桌面再装IDE要流畅得多。

5.4 在WSL里使用Docker

如果你想在Windows上使用Docker，有两个选择：装Docker Desktop，或者直接在WSL里安装Docker引擎。

Docker Desktop配置WSL集成后，会在后台使用WSL 2的虚拟机来运行Linux容器。这个方法比较省心，但Docker Desktop的许可证对大型企业可能收费，而且它本身比较吃内存。

如果你不想装Docker Desktop，直接在WSL里装Docker引擎也是可行的：

bash复制# 安装Docker引擎
sudo apt update
sudo apt install docker.io

# 启动Docker服务
sudo service docker start

# 验证Docker是否可用
sudo docker run hello-world

注意：WSL 2默认不通过systemd管理服务（新版WSL支持systemd，但需要手动开启），所以Docker服务要用 service docker start 而不是 systemctl start docker。如果你在WSL里执行 systemctl 命令报错，不是你的操作有问题，而是WSL默认没有启用systemd。在 /etc/wsl.conf 里添加 [boot] systemd=true 可以启用，之后就能用systemctl了。

6. 常见问题与排查技巧实录

6.1 安装和启动相关的典型报错

这一部分是我整理的一些高频问题，对照排查能节省大量时间。

6.2 docker相关命令找不到

有很多人在WSL里执行 docker-compose 时会收到这样的提示：

code复制The command 'docker-compose' could not be found in this WSL 1 distro.

先说结论：这个报错通常是因为你当前所在的发行版是一个WSL 1发行版（或者Docker Desktop的WSL集成设置不对），而 docker-compose 插件没有安装。解决办法：

1. 确认当前发行版是WSL 2：执行 wsl -l -v，如果Version列显示1，执行 wsl --set-version 发行版名 2 升级。
2. 安装 docker-compose-plugin 或者使用 docker compose（新版Docker已经集成）代替 docker-compose。

6.3 cmd打不开，Win加R故障

热搜词里那条“win加r打不开cmd”挺有意思。其实就是在Windows操作里，很多人发现按 Win + R 打开运行窗口后，输入 cmd 回车却没反应。这个问题跟WSL本身没有直接关系，但经常出现在折腾WSL/系统功能之后。

常见原因是系统环境变量里的 Path 被改坏了。排查方法：

• 按 Win + X，选择“系统”，点击“高级系统设置”，再点“环境变量”。
• 在“系统变量”里找到 Path，确保包含 C:\Windows\System32。
• 如果 Path 里多了某些不完整的路径，把它们删掉。

修完之后重新打开终端，应该就恢复正常了。这个问题为什么要特别提一句？因为在我折腾WSL的过程中，不止一次因为某些脚本自动修改了系统环境变量，导致cmd命令失效，排查了一圈才发现是Path的问题。

6.4 恢复出厂设置和重置WSL

如果WSL被折腾得乱七八糟，最彻底的办法是“恢复出厂设置”。先把需要的文件备份出来，然后执行：

bash复制# 查看当前安装的发行版
wsl --list --verbose

# 注销指定发行版（会删除该发行版的所有数据）
wsl --unregister Ubuntu-22.04

这个操作等于把WSL里所有的Linux文件系统删掉重来，速度很快，但请务必确认没有遗留重要文件。删除后重新执行 wsl --install -d Ubuntu-22.04 就可以全新安装。

如果你只是想重置某个发行版但保留在WSL里的整体配置，也可以先导出再注销再重新导入，参考前面目录迁移的流程。

6.5 WSL安装速度慢的优化方案

关于“wsl --install 太慢”这个问题，我再补充一个有效的方案：进入微软商店客户端，搜索Ubuntu，直接在商店页面里安装。微软商店的下载有时候比 wsl --install 内部的下载流程要稳定得多，因为走的是商店自己的CDN分发渠道。

还有一个思路：如果你有阿里云、华为云等国内云厂商的镜像源，安装完WSL后把apt源换成国内源，后续更新软件包的速度会快很多。Ubuntu 22.04的软件源配置文件是 /etc/apt/sources.list，建议备份后替换为国内镜像。

7. 几个值得养成的Shell使用习惯

7.1 用好补全和历史记录

Linux shell里最值得养成的习惯就是善用 Tab 键。输入命令、路径、文件名时按 Tab 可以自动补全，能省下大量时间。比如输入 cd /hom 之后按 Tab，shell会自动补全为 cd /home/。如果没补全，说明有多个可能的结果，再按一次 Tab 会列出所有匹配项。

另一个是历史记录。按上下方向键可以翻出之前执行过的命令。如果记不清了，用 Ctrl + R 进入反向搜索模式，输入关键字就能找到历史命令。这个功能我每天都要用十几次，非常顺手。

7.2 别名：把长命令变短

如果你经常执行一些又长又固定的命令，可以在 ~/.bashrc 文件里添加别名。比如：

bash复制alias ll='ls -alF'
alias gs='git status'
alias gp='git pull'

保存后执行 source ~/.bashrc 使配置生效。设置别名这个操作，本质上就是在简化重复劳动。每个开发者都应该有一份自己的 ~/.bashrc，把常用的快捷方式沉淀下来。

7.3 关闭WSL而不是直接关窗口

很多新手用完WSL是直接关闭终端窗口，但实际上Linux系统还在后台运行。长期这样操作，WSL会持续占用少量内存和CPU资源。想彻底关闭，在PowerShell里执行：

powershell复制wsl --shutdown

这个命令会停掉所有WSL运行实例。下次再打开终端进入WSL时，速度依然很快，不用担心启动慢的问题。也可以在 ~/.bashrc 里加一行提示，提醒自己在长时间不使用WSL时主动关闭。

8. 从Windows命令行到Linux Shell的一些心得体会

从最初在Windows上用PowerShell和CMD，到后来整个工作流迁移到WSL里，这个过程带给我最大的感受是：WSL把Windows和Linux两边的优势结合得很好。Windows负责日常办公、文档处理、桌面软件，WSL负责命令行开发、工具链、脚本自动化。我在Windows里写代码，然后在WSL里用Linux环境执行和调试，两边基本无缝衔接。

有时候我也会把WSL里跑通的一套流程移植到真正的Linux服务器上，几乎不需要改动。这让我在本地开发和线上部署之间的心智负担降低了很多——你不需要记两套完全不同的环境差异，一套bash脚本两头跑，省下大量时间。

这个过程其实踩过的坑不算少，有段时间我甚至因为WSL的虚拟内存占用问题纠结了很久。后来我意识到，与其纠结于某个具体的配置参数，不如把WSL当成一个可随时重置的沙盒环境，该迁移就迁移，该重装就重装，反正Linux环境的最大好处就是可以快速重建。只要你的 ~/.bashrc 和配置文件有备份，几分钟就能恢复一个趁手的环境。

如果你问我WSL有没有缺点，我会说：有些涉及底层硬件的操作，比如USB设备的直通访问，WSL的支持还不够完善。但就日常开发和shell使用来说，WSL已经足够成熟。最后再分享一个小技巧：如果你经常需要在Windows和WSL之间互相调用命令，可以试试在WSL里创建一个小脚本，把Windows的路径自动翻译成WSL路径，这样在两个世界之间穿梭时会更丝滑。