这几年做 Windows 开发的工程师,几乎都绕不开一个问题:怎么在 Windows 上用 Linux。编译、部署、跑中间件、写 shell 脚本、看线上日志,Linux 已经变成技术学习和日常开发的默认底座。但真正动手时,很多人的第一反应还是“装虚拟机”,随之而来的就是磁盘暴涨、内存吃紧、启动卡顿、文件来回拷贝,一整套流程跑下来,真正做事的精力已经被消耗掉大半。
如果只是要一个 Linux 环境来学习、开发、调试、跑服务,其实有一条更轻、更快的官方路线:Windows Subsystem for Linux,也就是常说的 WSL。它是微软官方提供的 Linux 运行环境,不需要额外装 VMware 或 VirtualBox,也不需要下载完整的 Linux 桌面镜像,两条命令就能把 Ubuntu 跑起来,而且能和 Windows 文件系统、端口、剪贴板直接互通。
这篇文章会从“为什么不用虚拟机”开始,把 WSL 的安装、配置、日常使用、场景对比和常见问题完整拆开。看完之后,你能自己判断什么时候该用 WSL,什么时候还得回到虚拟机,也能在 Windows 上快速搭好一套能用的 Linux 开发环境。
1. 虚拟机方案的问题与 WSL 的价值
1.1 虚拟机到底卡在哪
虚拟机不是不好,它只是“太重”。
以 VMware Workstation 为例,安装一个带桌面环境的 Ubuntu,ISO 文件大概 2 到 4GB,虚拟机磁盘动辄预留 20 到 40GB。启动之后,内存至少要划分 2GB,如果同时跑 Windows 开发和虚拟机里的服务,16GB 内存会觉得非常紧张。
文件互传也是一个痛点。虽然 VMware 提供了 VMware Tools 和共享文件夹,但实际配合开发工具使用时,经常遇到路径映射、权限不一致、监听地址不通等问题。很多工程师的真实状态是:虚拟机里敲代码,Windows 里用 IDE 和浏览器,两边来回切换,体验并不顺畅。
1.2 WSL 解决的是哪一类需求
WSL 的目标场景很明确:你需要的不是一整个 Linux 桌面系统,而是一个能跑 Linux 命令、Linux 软件、Linux 服务的环境。
它用 Windows 的系统机制直接承载 Linux 用户态程序,交互成本远低于虚拟机。在 WSL 里安装一个 redis、nginx、Python 环境,和在 Linux 服务器上做几乎一样;但与 Windows 的互通又比虚拟机方便得多,访问 Windows 磁盘直接走/mnt/c/,启动 Windows 可执行文件也只需输入完整路径。
所以更稳妥的判断是:WSL 不是要杀死虚拟机,而是补上了虚拟机和双系统覆盖不到的中间地带,也就是“轻量开发环境”这个使用场景。
1.3 什么样的读者最该读这篇文章
- 开发环境在 Windows,但部署目标在 Linux 的工程师。
- 刚学 Linux,想快速上手命令而不用折腾整个系统的学习者。
- 需要在本地安装 Linux 中间件做验证的 Java、Python、前端开发者。
- 已经被 VMware 占用大量磁盘和内存,想找替代方案的运维或测试工程师。
如果你需要完整图形化桌面、需要运行对硬件设备要求高的程序、需要测试 Linux 内核级功能,那么 WSL 未必合适,虚拟机甚至物理机仍然是更好的选择。这个边界需要一开始就说清楚。
2. WSL 的核心概念与运行原理
2.1 WSL 是什么,兼容到什么程度
WSL 的官方定义是“适用于 Linux 的 Windows 子系统”,它允许开发者在 Windows 上直接运行 Linux 发行版,不需要安装虚拟机软件,也不需要单独准备 Linux 内核镜像。
目前有两个主要版本:WSL1 和 WSL2。
WSL1 的实现方式是系统调用翻译,把 Linux 程序的系统调用转换成 Windows 内核能识别的调用。好处是启动快、文件访问延用 Windows 文件系统、跨文件读写性能好;但代价是某些依赖 Linux 内核特性的程序无法运行。
WSL2 则完全改变了架构,它在 Windows 内部运行一个轻量级虚拟机,里面是真正的 Linux 内核。兼容性比 WSL1 高得多,Docker、systemd、绝大多数 Linux 软件都能跑。
2.2 WSL2 的“轻量级虚拟机”到底轻在哪里
从技术角度看,WSL2 确实用了虚拟化技术,底层依赖 Hyper-V 虚拟机监控程序。但它和用户平时使用的 VMware 虚拟机完全不同:
- 启动极快,打开终端几秒钟就能进入 Linux。
- 内存按需分配,可以限制上限。
- 不需要图形化界面,不占桌面资源。
- 与 Windows 的剪贴板、文件、端口天然打通。
简单理解,WSL2 是微软为你封装好的一个小型 Linux 运行容器,你只看到终端,不需要去维护虚拟机硬件配置。
2.3 为什么用 WSL 能降低开发成本
它真正降低的是四件事:环境准备成本、磁盘资源成本、文件互通成本、日常切换成本。
传统模式下,为一个 Redis 测试环境装虚拟机,要分配内存、装系统、配网络、设置共享目录。而 WSL 模式下,安装 Linux 发行版可以理解为“安装一个应用”,启动和关闭都非常快,资源占用也更可控。
3. 环境准备与前置条件
3.1 系统版本要求
WSL 已经集成在 Windows 10 2004 及以上版本和 Windows 11 中。较老版本可以通过系统更新或启用可选功能安装。
更稳妥地讲,版本要求会因为 WSL 功能的演进而变化。如果你用的是 Windows 10 较老版本,建议先更新系统,再运行 WSL 安装命令。如果提示找不到命令,通常就是系统版本过低或者未安装相应组件。
3.2 必须开启的 Windows 功能
安装 WSL 前,需要确保以下功能已启用:
- 适用于 Linux 的 Windows 子系统(Windows Subsystem for Linux)
- 虚拟机平台(Virtual Machine Platform)
如果使用 WSL2,还需要在 BIOS 中开启虚拟化技术,一般是 Intel VT-x 或 AMD-V。
在 PowerShell 中以管理员身份执行以下命令,可以快速启用所需功能:
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行之后,重启系统。
3.3 检查您的计算机是否支持
在 Windows 的任务管理器中切换到“性能”选项卡,查看 CPU 部分是否显示“虚拟化:已启用”。如果显示“已禁用”,需要进入 BIOS 开启虚拟化功能。
如果公司电脑被统一管理,权限受限的情况下,可能需要联系管理员协助,或者考虑使用云服务器方案,而不是强行在本机安装 WSL。
4. 在 Windows 上安装 Linux 的完整流程
4.1 使用官方命令安装 WSL
从 Windows 10 2004 和 Windows 11 开始,最简单的安装方式是直接运行:
wsl --install这条命令会完成以下操作:
- 安装 WSL2。
- 启用相关 Windows 功能。
- 默认安装 Ubuntu 发行版。
执行后根据提示重启系统。重启完成后,Windows 会自动打开 Ubuntu 终端,要求你设置新的 Linux 用户名和密码。
注意,wsl --install在部分最新版本还会自动安装 Windows Terminal,进一步提升使用体验。
4.2 安装指定 Linux 发行版
如果你不想使用默认的 Ubuntu,可以先查看可供安装的发行版列表:
wsl --list --online输出会显示类似Ubuntu-22.04、Ubuntu-24.04、Debian、kali-linux、openSUSE等发行版名称,然后通过-d参数安装:
wsl --install -d Debian发行版名称以你本机wsl --list --online实际输出为准,不同版本或不同地区可能略有差异。
4.3 从微软商店安装发行版
如果命令行方式遇到问题,也可以打开 Microsoft Store,搜索“Ubuntu”或“Debian”等关键字,点击安装,然后从开始菜单启动。
这种方式适合 Windows 家庭版或者命令行权限受限的场景。应用商店方式安装的发行版,和命令行方式安装的发行版,在本质上没有区别。
4.4 安装后的首次启动
首次启动时,Linux 系统会引导你创建用户名和密码。这里的用户名是 Linux 系统内的用户,与 Windows 用户名无关。创建完成后,你就进入了一个完整的 Linux shell 环境。
检查一下系统版本:
cat /etc/os-release uname -a如果能看到类似 Ubuntu 的发行版名称,以及microsoft-standard-WSL2的内核信息,说明安装成功。
5. 安装后的基础配置与优化
5.1 更新软件源和系统软件
进入 WSL 后,第一步建议更新软件包索引:
sudo apt update sudo apt upgrade -y国内网络环境下,apt update可能较慢,可以把软件源替换为国内镜像源。这一步不是必需的,但能显著提升安装软件的速度。
替换软件源的核心思路是备份原文件并写入新镜像源。以 Ubuntu 为例,编辑/etc/apt/sources.list,将archive.ubuntu.com替换为对应镜像地址,然后重新执行sudo apt update。
5.2 在 WSL 中安装运行 Linux 软件
安装软件的方式和普通 Linux 一样。以 Nginx 为例:
sudo apt install nginx -y sudo service nginx start启动后,在 Windows 浏览器中访问http://localhost,如果看到 Nginx 欢迎页,就说明 WSL 中的服务已经正常跑起来了,并且端口已经自动映射到了 Windows 本机。
再比如安装 Redis:
sudo apt install redis-server -y sudo service redis-server start使用redis-cli ping验证,返回PONG即表示运行正常。
WSL2 在较新版本中默认使用 NAT 网络模式,Windows 访问 WSL 中的服务一般不需要额外配置,比较适合本地开发验证。
5.3 配置默认版本和发行版管理
如果你安装了多个发行版,需要了解常用的管理命令:
# 查看已安装的发行版及其状态 wsl --list --verbose # 设置 WSL 默认版本为 2 wsl --set-default-version 2 # 切换默认发行版 wsl --set-default Ubuntu # 将某个发行版从 WSL1 迁移到 WSL2 wsl --set-version Ubuntu 2判断当前发行版使用的是 WSL1 还是 WSL2,可以在 PowerShell 运行wsl --list --verbose,或者进入 Linux 后运行:
uname -r如果内核版本信息中包含microsoft-standard-WSL2,说明正在使用 WSL2。
5.4 限制 WSL2 的资源占用
WSL2 默认可能会占用较多内存,开发机上如果同时运行多个程序,建议设置资源上限。在 Windows 用户目录下创建.wslconfig文件,示例如下:
[wsl2] memory=4GB processors=2 swap=2GB然后执行wsl --shutdown并重新打开 WSL 生效。内存和 CPU 数量请根据本机实际情况调整,不必照搬。
6. WSL 与虚拟机、双系统、云主机的真实对比
在实际技术选型时,不能只凭“不用虚拟机”这个标题做决定,需要从多个维度对比。
| 对比维度 | WSL | 虚拟机(VMware) | 双系统 | 云服务器 |
|---|---|---|---|---|
| 安装复杂度 | 低,命令即可 | 中,需要镜像和配置 | 高,需要分区和引导 | 低,但需要购买 |
| 启动速度 | 秒级 | 慢 | 需要重启 | 取决于网络 |
| 磁盘占用 | 小 | 大 | 大 | 无本地占用 |
| 图形界面 | 不支持完整桌面 | 支持 | 支持 | 不支持 |
| 文件互通 | 好,直接访问 | 一般,需共享目录 | 差,需单独分区 | 差,需传输 |
| 生产环境一致性 | 较好 | 好 | 好 | 最好 |
| 适用场景 | 日常开发、脚本、中间件验证 | 完整Linux桌面、内核实验 | 长期单一系统使用 | 线上部署、隔离环境 |
从表格可以看到,WSL 的强项是轻量、快速、开发友好;但如果需要完整桌面级体验,或者需要测试 Linux 内核行为,虚拟机和物理机仍然有不可替代的位置。
另一个容易被忽略的是 Docker 场景。WSL2 已经成为 Docker Desktop on Windows 的默认后端,意味着本地用 Docker 跑容器时,实际是运行在 WSL2 的轻量虚拟机里的。这也意味着你并不需要先手动装好 WSL,Docker Desktop 安装过程也会帮你处理大部分底层配置。
7. 实际开发场景:从 WSL 操纵 Windows 文件
7.1 在 WSL 中访问 Windows 磁盘
WSL 会把 Windows 的各个盘符自动挂载到/mnt目录下。例如,C 盘对应/mnt/c,D 盘对应/mnt/d。
cd /mnt/c/Users/你的用户名/Desktop ls -la这个特性非常便于在熟悉的 Windows 目录结构下进行 Linux 操作。
7.2 在 Windows 中打开 WSL 的文件目录
反向操作也很简单。在 WSL 内运行explorer.exe .(注意后面有个点)可以在 Windows 资源管理器中打开当前 WSL 目录:
explorer.exe .WSL 中的文件系统在 Windows 中会以网络路径形式出现,Windows 环境变量\\wsl$\<发行版名>\可以直接访问。两者互通,但读写性能表现不同,这一点后文还会强调。
7.3 Windows 与 Linux 命令互相调用
WSL 支持跨系统调用。在 PowerShell 中运行:
wsl ls -la可以执行当前默认发行版中的命令。在 WSL 中,也可以调用 Windows 可执行文件:
notepad.exe test.txt powershell.exe Get-Process这种互操作能力,让 Windows 和 Linux 环境不再像过去那样孤立。
8. 常见问题与排查方法
WSL 使用中有几个问题是高频出现的,下面用表格整理。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 提示“适用于 Linux 的 Windows 子系统必须更新到最新版本才能继续” | 当前 WSL 组件版本较老,或内核组件缺失 | 在 PowerShell 运行wsl --version和wsl --status查看状态 | 运行wsl --update更新 WSL 并重启 |
wsl --install执行后长时间无响应 | 网络原因导致发行版下载中断 | 检查网络连接,查看是否卡在“正在下载”阶段 | 稍后重试,或改用 Microsoft Store 安装发行版 |
| 提示“请启用适用于 Linux 的 Windows 子系统” | Windows 功能未完整开启 | 在 PowerShell 用dism.exe检查功能状态 | 重新启用相应功能并重启 |
| VMware 中安装 Linux 后无法开机或蓝屏 | Hyper-V 与 VMware 冲突 | 查看错误码,确认是否同时开启 Hyper-V | 二选一,或使用只支持 WSL2 的虚拟化方案 |
| WSL2 内存占用过高 | WSL2 默认可使用较多内存 | 打开任务管理器查看 Vmmem 进程 | 创建.wslconfig限制上限并wsl --shutdown生效 |
| 无法打开 WSL 的本地服务 | 端口被占用或防火墙拦截 | 在 WSL 内curl localhost:端口验证 | 检查 Windows 防火墙规则,确认服务监听 0.0.0.0 |
在/mnt/c下执行chmod不生效 | Windows 文件系统不支持完整 Linux 权限模型 | 查看文件系统挂载类型 | 将工作目录放在 WSL 内部文件系统,而不是/mnt下 |
wsl --list --verbose显示版本为 1 | 未设置默认版本或系统虚拟化未开启 | 检查 BIOS 虚拟化设置 | 运行wsl --set-version 发行版名 2升级 |
8.1 关于 VMware 和 WSL 的冲突
在开发环境中,如果已经安装了 VMware 并依赖其运行虚拟机,再启用 WSL2 时要注意潜在冲突。
WSL2 依赖 Windows 的虚拟化平台,而传统 VMware 在未适配时,可能无法与同时开启的 Hyper-V 组件共存。实际表现常见于:
- 打开 VMware 虚拟机时提示无法连接到虚拟机,或者无权运行该程序。
- 启动虚拟机后直接蓝屏。
- 虚拟机网络模式异常,桥接模式无法工作。
遇到这种情况,可以根据需求二选一。如果日常以 WSL 开发为主,建议关闭 VMware;如果必须使用完整虚拟机,可以关闭 Windows 的“虚拟机平台”功能,暂时改用 WSL1,或者调整 VMware 的相关配置。但更稳妥的做法是先在测试环境验证,不要在生产强依赖的环境里随意切换虚拟化开关。
8.2 WSL 更新失败的可能路径
如果wsl --update失败,通常的原因包括系统版本偏旧、网络下载失败、或者 Windows 更新组件异常。可以尝试:
wsl --update --web-install如果依然失败,先运行 Windows Update 检查系统补丁,再重试。也可以去微软官方文档页面查看 WSL 的更新发布说明,对照当前系统版本定位问题。
9. 最佳实践与工程建议
9.1 工作目录放在 WSL 内部
WSL2 访问 Windows 文件系统(/mnt/c/)时,会经过跨系统转换,性能明显低于 WSL 自身的 Linux 文件系统。因此建议项目代码、编译产物、配置文件都放在 WSL 内部,比如~/projects,再通过 Windows 侧工具访问。
这样既保障了性能,也避免了权限模型不兼容的问题。
9.2 统一使用 Windows Terminal
Windows Terminal 是微软官方的高级终端工具,可以同时打开多个 WSL 发行版、PowerShell、CMD 等多个标签页,支持配置主题、字体和快捷键。安装命令:
winget install Microsoft.WindowsTerminal在开发中,它会比默认的命令提示符窗口舒服得多。
9.3 注意 systemd 的启动方式
较新版本的 WSL 已经支持 systemd。如果你需要在 WSL 中管理多个系统服务,可以编辑/etc/wsl.conf:
[boot] systemd=true然后重启 WSL,就能用systemctl管理服务。如果使用的发行版较老,建议直接在 shell 里用service命令启动守护进程。
9.4 管理多发行版时的规范
如果安装了多个发行版,建议在.wslconfig或终端配置中固定默认发行版,避免命令执行的歧义。同时,为每个发行版设置独立工作目录,并使用wsl --set-default明确默认入口。
9.5 安全与权限意识
WSL 不是沙箱,它拥有访问 Windows 文件系统的能力。在 WSL 中使用sudo时,同样需要清楚自己执行的操作。不要随意运行来源不明的脚本,不要用 root 用户处理日常业务,修改/etc/下的系统配置时先备份。涉及生产环境的操作,无论在 WSL 还是虚拟机中,都应遵守最小权限原则,并在测试环境验证后再执行。
9.6 什么时候你应该关掉 WSL
如果你发现自己一直在 WSL 里寻找图形化软件,或者需要频繁使用 Linux 桌面,说明 WSL 并不适合当前需求,这时应该考虑虚拟机或物理机。WSL 的定位是开发工具链的一部分,不是完整桌面替代品,强行把所有需求都搬进去会带来不必要的复杂度。
10. 总结与后续学习方向
Windows 上使用 Linux,虚拟机不再是唯一选择。WSL 用更轻的架构解决了大部分日常开发场景:秒级启动、低资源占用、Windows 与 Linux 文件互通、命令行体验完整,还能直接支撑 Docker Desktop 这类开发工具。
这篇文章主要讲清楚了 WSL 与虚拟机的边界、WSL1 与 WSL2 的区别、从零安装发行版、多发行版管理、资源限制、文件互操作,以及 VMware 冲突和 WSL 更新失败等高频问题的排查思路。这些内容足够支撑你完成从“没有 Linux 环境”到“在 Windows 上顺畅运行 Linux 工具链”的转型。
下一步建议先跑通一个最小场景:安装 Ubuntu,装一个 Nginx 或 Redis,用 Windows 浏览器访问,再尝试把一个小项目放到 WSL 的~/projects里编译运行。走完这个流程,你对 WSL 的体感会完全不一样。
如果想要继续深入,可以学习 WSL 的.wslconfig调优、Windows Terminal 的主题配置、Docker Desktop 与 WSL2 的集成细节,以及 shell 脚本和 Linux 常用命令的组合使用。建议把这篇教程里的排错表格收藏起来,遇到问题时直接对照排查。