不用虚拟机也能在 Windows 上安装使用 Linux这句话在十多年前还只能靠 Cygwin 这类兼容层勉强实现。真正把这件事变成正规开发路径的是 Windows 10 开始提供的“适用于 Linux 的 Windows 子系统”也就是 WSL。它不需要你安装 VMware 或 VirtualBox不需要手动划分内存、磁盘和网络也不需要经历“启动虚拟机、等待内核、进入桌面”的完整流程。对于只需要 Linux 命令行、shell 脚本、Node.js、Python、Go 等服务端开发场景的 Windows 用户来说WSL 是成本最低、启动最快、和 Windows 文件互访最方便的 Linux 使用方式。下面按一条完整主线展开先用对比说明为什么可以不用虚拟机再确认 Windows 环境是否满足安装条件然后完成 WSL2 的安装、初始化和基本配置接着说明 Windows 与 Linux 之间如何互访文件和互相调用命令最后给出安装启动阶段最常见报错的排查思路和生产级使用建议。读完可以自己完成从“Windows 无法运行 Linux 命令”到“在 Windows 终端里稳定使用 Ubuntu 环境”的完整链路并把这套环境用于日常脚本开发和项目调试。1. 为什么在 Windows 上运行 Linux 可以不用虚拟机1.1 传统虚拟机方案的主要成本传统虚拟机方案不是不能用而是成本集中在“管理”上。安装 VMware 或 VirtualBox 之后你要下载 Linux 镜像 ISO创建虚拟机分配 CPU 核数、内存大小、磁盘空间还要处理虚拟网卡、共享文件夹和快照策略。一台 16GB 内存的 Windows 电脑给虚拟机分 4GBWindows 就只剩 12GB 可用磁盘上再创建一个 40GB 的动态虚拟磁盘SSD 剩余空间也会肉眼可见地减少。虚拟机启动后用户看到的是完整桌面但日常开发真正需要的往往是那个黑色终端而不是桌面里的浏览器和文件管理器。如果你只是需要 Linux 环境来跑脚本、编译前端项目、启动后端服务、执行测试命令那么完整虚拟机的启动时间、资源占用和文件交换成本都会让“只写几行命令”这件小事变得很重。这也是 WSL 出现的直接原因大多数 Linux 使用场景并不需要完整桌面和独立内核管理需要的是一个和 Windows 无缝衔接的 Linux 运行环境。1.2 WSL 到底是什么它的工作方式有什么不同WSL 是 Windows Subsystem for Linux 的缩写中文全称是“适用于 Linux 的 Windows 子系统”。它由微软官方提供作用是让 Linux 二进制程序能直接在 Windows 上运行。WSL 有两代实现工作原理差别很大WSL1 是一个系统调用翻译层。Linux 程序发出的系统调用会被 Windows 内核翻译成对应的 Windows 系统调用。这种方案启动极快但遇到复杂的内核特性或系统调用时翻译层可能出现兼容性问题。WSL2 使用了一个由 Windows 托管的轻量级虚拟机里面运行的是真正的 Linux 内核。用户不需要手动创建虚拟机、不需要指定内存和 CPU、不需要安装 VMToolsWindows 会在需要时自动启动这个运行环境。这里要澄清一个容易误解的点标题说“不用虚拟机”指的是用户不需要自己搭建和维护虚拟机。WSL2 在底层确实借用了轻量虚拟化技术但它与传统虚拟机的管理体验完全不同。用户面对的是一个普通终端Windows 负责管理内核启动、内存回收和磁盘生命周期而不是让你去配置一台“机器”。1.3 WSL1 和 WSL2 的选择依据虽然新版本默认推荐 WSL2但了解两者的差异仍然很重要因为某些老机器或特殊场景下 WSL1 反而更合适。对比项WSL1WSL2系统调用兼容性翻译层实现部分复杂调用不兼容真实 Linux 内核兼容性更高启动速度极快几乎没有额外开销快但比 WSL1 多一个轻量虚拟机启动过程Linux 文件系统读写性能相对较慢使用 ext4 文件系统编译和 git 操作明显更快跨系统文件访问性能直接访问速度尚可访问 /mnt/c 时存在明显性能损耗是否需要开启虚拟化不需要需要 VirtualMachinePlatform 和 BIOS 虚拟化支持适合场景旧电脑、简单命令行、不能开启虚拟化的环境Docker、本地编译、跑服务等绝大多数开发场景新安装的环境默认使用 WSL2。如果电脑太老或者出于安全策略无法开启 BIOS 虚拟化WSL1 也能完成基础命令行工作只是复杂工具链的兼容性要差一些。2. 安装前先确认 Windows 环境和前置条件2.1 系统版本和构建号要求WSL2 对 Windows 版本有明确要求。Windows 10 2004 版本build 19041及以上以及 Windows 11 各版本都可以使用完整 WSL 功能。更早的 Windows 10 版本虽然能改造成 WSL1但体验不完整建议直接升级系统。查看本机版本最简单的方式是按下Win R输入winver回车弹窗里会显示系统版本和内部版本号。也可以用 PowerShell 执行[System.Environment]::OSVersion.Version如果版本等于或高于 19041就可以继续。需要注意这里只代表系统满足基本条件具体安装结果还受 Windows 功能状态、虚拟化开关和网络环境影响。系统版本推荐安装方式说明Windows 11wsl --install组件、内核、发行版一键完成Windows 10 2004 及以上wsl --install大部分环境可用个别企业策略会限制下载Windows 10 1909 及更早手动开启功能后安装 Store 发行版不推荐升级系统后体验完整2.2 需要开启的可选功能WSL 依赖 Windows 的两个可选功能一个是“适用于 Linux 的 Windows 子系统”另一个是“虚拟机平台”。第二个只有 WSL2 需要但为了使用完整功能建议两个都开启。可以用管理员身份打开 PowerShell执行下面的命令dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart也可以走图形界面打开“控制面板 - 程序 - 启用或关闭 Windows 功能”在列表里勾选这两项然后点击确定。这里有一个新手最容易漏掉的点开启功能后必须重启电脑。不是“等一会就生效”而是 Windows 需要完成组件安装重新启动后命令才能正常使用。很多人执行完dism命令后直接输入wsl报“不是内部或外部命令”就是没重启。WSL2 还要求在 BIOS 里开启虚拟化。检查方法打开任务管理器切到“性能”标签页选择 CPU右下角如果显示“虚拟化已启用”说明硬件虚拟化是开着的。如果显示“已禁用”需要进入 BIOS 找到 Intel VT-x 或 AMD SVM 选项并打开。2.3 学习环境与生产环境的区别学习环境里可以随意折腾发行版装坏了就注销重装。生产环境则要多想几步WSL 里的代码和数据要定期备份系统更新前要确认服务兼容性资源分配要预留 Windows 侧余量不能把整个 CPU 和内存都交给 WSL。一个实用的原则是学习环境用默认配置项目环境用.wslconfig限制资源并且把/etc/wsl.conf、Shell 配置文件和项目代码纳入 Git 或备份工具管理。企业电脑如果被组策略限制安装需要先联系管理员确认不要绕过系统策略强行修改。3. 一条命令完成安装并初始化发行版3.1 使用 wsl --install 安装默认发行版WSL 的现代安装方式非常简洁。以管理员身份打开 PowerShell执行wsl --install这条命令会依次完成三件事启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”两个功能下载安装最新 WSL 内核安装默认的 Ubuntu 发行版。命令结束后如果提示需要重启就先重启再继续下一步。如果想安装指定发行版可以先查看可用的在线发行版列表wsl --list --online输出结果类似下面这样以下适用于 Linux 的 Windows 子系统发行版可用 NAME FRIENDLY NAME Ubuntu Ubuntu Ubuntu-22.04 Ubuntu 22.04 LTS Debian Debian GNU/Linux kali-linux Kali Linux Rolling然后安装指定版本wsl --install -d Ubuntu-22.04这一阶段最常见的坑是下载发行版时网络不稳定导致安装卡在下载阶段。可以换一个发行版重试或者用--install -d Ubuntu安装默认 LTS 版本。3.2 首次启动创建 Linux 用户和密码安装完成后桌面上会出现 Ubuntu 图标或者在开始菜单里找到刚刚安装的发行版并启动。首次启动会要求创建 Linux 用户名和密码Enter new UNIX username: zhangsan New password: Retype new password:这里的用户名和 Windows 用户名可以不同密码输入时不会显示字符这是正常现象。创建完成后登录进入 Linux 终端先做一次系统更新sudo apt update sudo apt upgrade -y验证环境是否正常whoami uname -r cat /etc/os-release如果能输出用户名、Linux 内核版本和 Ubuntu 版本信息说明 WSL 基本环境已经可用。3.3 确认使用 WSL2 版本安装完成后查看发行版当前运行在 WSL1 还是 WSL2wsl --list --verbose输出中的VERSION列如果是2说明已经在使用 WSL2。如果是1需要把默认版本切换成 WSL2wsl --set-default-version 2 wsl --set-version Ubuntu 2切换过程会占用一些时间完成后再次执行wsl --list --verbose确认。这一步很重要因为 Docker、systemd 等大量开发特性只有在 WSL2 下才完整可用。检查 WSL 自身是否最新wsl --status wsl --version输出中的WSL 版本如果偏旧执行wsl --update保持内核和组件处于较新状态可以减少很多兼容性报错。3.4 最小功能验证为了确认环境可以正常编写和运行程序可以在 Linux 终端里做一次最小脚本验证echo Hello from WSL /tmp/test.txt cat /tmp/test.txt chmod x /tmp/test.txt再验证 Python 和 Node.js 这类常见运行时是否存在python3 --version node --versionUbuntu 默认不一定自带 Node.js如果输出提示找不到命令可以后续用apt或nvm安装。这一步的目的不是安装工具而是确认终端交互、文件写入和命令解析都正常。4. Windows 和 Linux 之间的文件与命令互访4.1 从 Windows 侧访问 Linux 文件在 Windows 资源管理器地址栏输入下面的路径可以直接打开 WSL 发行版的文件系统\\wsl.localhost\Ubuntu旧版 WSL 使用的路径是\\wsl$\Ubuntu如果上面的地址打不开就换成这个。Linux 主目录/home/zhangsan对应的 Windows 路径是\\wsl.localhost\Ubuntu\home\zhangsan在这个目录里可以把 Windows 下载的文件复制进 Linux 环境也可以把 Linux 生成的日志复制出来。但这里必须提醒一个高频坑不要用 Windows 记事本、写字板或普通编辑器直接修改 Linux 内部的文件。Windows 工具会把文本保存为 CRLF 换行符还会改变文件的权限元数据导致脚本在 Linux 里执行时报错。推荐做法是安装 Visual Studio Code 的 Remote-WSL 插件在 Linux 终端里执行code .此时 VS Code 会以 WSL 环境身份打开项目编辑保存和文件权限都由 Linux 侧处理。4.2 从 Linux 侧访问 Windows 磁盘WSL2 会自动把 Windows 的磁盘挂载到/mnt目录下。C:盘对应/mnt/cD:盘对应/mnt/d。cd /mnt/c/Users/zhangsan/Desktop ls -la通过这种方式Linux 里的命令可以直接操作 Windows 的文件。例如在 Linux 里查看 Windows 桌面上的文件、把日志写到 Windows 目录里都是可行的。但性能问题要注意。在 WSL2 中访问/mnt/c下的文件底层走的是 9P 协议Windows 和 Linux 之间的文件元数据需要相互转换大量小文件操作会明显变慢。npm install、git status、编译大型项目这类操作如果项目目录在/mnt/c速度可能比在 Linux 文件系统里慢数倍。所以最佳实践是项目代码、依赖目录、数据库数据文件都放在 WSL 的 Linux 文件系统里建议统一放在~/projects下。只有需要和 Windows 侧软件交换的少量文件才放到/mnt/c。4.3 在 PowerShell 或 CMD 中直接调用 Linux 命令WSL 的另一个便利点是可以在 Windows 终端里直接调用 Linux 命令而不必进入 Ubuntu 终端wsl uname -a wsl python3 --version wsl ls -la /home wsl -d Ubuntu-22.04 -- curl -s https://example.comwsl 命令会把命令交给默认发行版执行wsl -d 发行版名 -- 命令则指定某一个发行版。执行时的工作目录默认是 Windows 当前目录对应的/mnt/c位置所以在 PowerShell 里先cd到某个项目目录再执行wsl make build效果等同于在 Linux 里进入该目录执行。反向互操作也存在在 WSL 终端里可以直接执行 Windows 程序例如notepad.exe、explorer.exe因为 WSL 默认会把 Windows 的 PATH 追加进 Linux 的 PATH。不过这种混用只适合临时操作不要在脚本里大量依赖它否则脚本部署到纯 Linux 服务器时会因为找不到xxx.exe而挂掉。5. 用 wsl.conf 和 .wslconfig 控制运行行为5.1 Linux 侧的 /etc/wsl.conf/etc/wsl.conf位于发行版的 Linux 文件系统里用来控制 WSL 启动发行版时的行为。文件默认可能不存在可以用sudo创建并编辑。[boot] systemdtrue [user] defaultzhangsan [network] generateResolvConftrue [interop] enabledtrue appendWindowsPathtrue [automount] enabledtrue optionsmetadata,umask22,fmask11各段含义如下[boot] systemdtrue让 WSL 使用 systemd 作为系统初始化程序这样才能用systemctl管理服务。[user] defaultzhangsan指定进入 WSL 后默认登录的用户。如果忘了设置每次进入会是默认用户可能不是自己创建的那个用户。[network] generateResolvConftrue让 WSL 自动生成/etc/resolv.conf。如果这个值为false常会导致 Linux 内无法解析域名。[interop]控制是否允许从 Linux 调用 Windows 程序以及是否把 Windows PATH 追加进来。日常开发保持enabledtrue。[automount]控制 Windows 盘符自动挂载。metadata选项允许挂载时保留 Linux 文件权限umask和fmask决定权限掩码。修改后执行wsl --shutdown再重新进入 WSL配置才会生效。wsl --shutdown这个命令会把当前所有 WSL 发行版全部停掉不影响 Windows 侧的数据但已打开的终端会断开。5.2 Windows 侧的 .wslconfig.wslconfig位于 Windows 用户目录下路径是C:\Users\你的用户名\.wslconfig用来控制 WSL2 虚拟机的全局资源分配。它只对 WSL2 生效WSL1 不读取这个文件。[wsl2] memory4GB processors4 swap4GB localhostForwardingtrue参数含义常见值错误配置的表现memoryWSL2 最多可用的内存4GB 或 8GB设置过高会使 Windows 侧内存紧张系统卡顿processorsWSL2 最多可用的 CPU 核数2 到 4设置过高会影响 Windows 前台应用的响应速度swapWSL2 使用的交换文件大小与内存相当或略大设置过小内存不足时会出现 OOM 杀进程localhostForwardingLinux 内监听端口是否映射到 Windows 的 127.0.0.1默认 true设为 false 后Windows 浏览器无法访问 WSL 里的服务端口这里的核心思考是WSL2 作为一个轻量虚拟机内存分配是受限的。如果不写memoryWSL2 可能会按宿主机内存的一定比例占用机器内存较小时会影响 Windows 自身。如果是 16GB 内存的机器给 WSL2 分配 4GB 是一个稳妥起点如果是 32GB可以分到 8GB。修改.wslconfig后同样需要wsl --shutdown才能生效。5.3 systemd 开启后的变化早期 WSL 不提供 systemd用户无法用标准的systemctl管理服务安装 Docker 后只能手动执行dockerd体验和真实 Linux 差别很大。现在 WSL 已经支持 systemd在/etc/wsl.conf里开启systemdtrue后就能获得接近真实服务器的服务管理体验。开启后安装并启动 Docker 服务的流程变成sudo systemctl enable docker sudo systemctl start docker systemctl status docker还能用systemd-analyze查看启动耗时用journalctl查看服务日志。对于需要在本机模拟生产环境的人来说这一步很重要。代价是开启 systemd 后WSL 启动时间会略有增加因为需要初始化完整的系统服务树。学习环境下可以暂时关闭但准备长期使用 WSL 做项目开发时建议直接开启按真实 Linux 的环境习惯来维护。6. 安装和启动阶段常见的报错与排查6.1 提示“适用于 Linux 的 Windows 子系统必须更新到最新版本才能继续”这是非常常见的一条报错完整提示类似适用于 Linux 的 Windows 子系统必须更新到最新版本才能继续。 可通过运行 “wsl.exe --update” 来更新。原因通常是 WSL 组件版本过旧而你要安装的发行版或内核功能需要更新版本。处理方式是以管理员身份打开 PowerShell执行wsl --update如果更新过程提示下载失败先确认系统时间正确、网络连接正常再重试。更新完成后重启终端重新进入发行版。预防建议不要长时间不更新 WSL定期执行wsl --update能避免不少和内核相关的异常。6.2 安装发行版时报 0x8007019e 或 0x800700030x8007019e 常见于 Windows 功能未完整启用。检查“启用或关闭 Windows 功能”里两项是否都已勾选如果已勾选但仍报错先重启电脑再重试。0x80070003 通常和系统盘空间不足、安装目录权限异常或功能未启用有关。先检查 C 盘剩余空间清理后再执行wsl --install -d Ubuntu-22.04如果系统盘空间确实紧张较新的 WSL 版本支持在安装时指定位置。可以执行wsl --help查看是否包含--location参数然后把发行版安装到其他磁盘。不同版本对参数的支持不一样落地前先看本机帮助不要直接抄写网上旧命令。安装失败时还有一个通用排查技巧进入事件查看器在“Windows 日志 - 应用程序”里搜索和 WSL、VirtualMachinePlatform 相关的错误记录很多 0x 开头的错误码都可以在这里找到更详细的原因。6.3 WSL2 启动失败提示虚拟化未启用或内核组件缺失如果电脑支持虚拟化但没在 BIOS 里开启或者虚拟机平台功能未启用WSL2 会启动失败报错类似请启用虚拟机平台 Windows 功能并确保在 BIOS 中启用虚拟化。按下面的顺序排查打开任务管理器确认“虚拟化”为已启用。如果禁用进入 BIOS 开启 Intel VT-x 或 AMD SVM。确认 Windows 功能里的“虚拟机平台”已勾选并重启。执行wsl --update更新内核组件。如果报错代码是 0x80370102 或 0x800701bc优先怀疑虚拟化平台未启用或 WSL 内核未更新处理方法同上。如果 BIOS 虚拟化确实无法开启兼容方案是把该发行版降级回 WSL1wsl --set-version Ubuntu 1WSL1 不依赖虚拟机平台但功能会比 WSL2 少一些。6.4 常见问题速查表问题现象可能原因检查方式处理建议wsl命令无法识别WSL 未安装或环境变量异常where wsl管理员 PowerShell 执行wsl --install安装发行版一直卡在下载网络不稳定下载中断观察下载进度是否长时间不动更换发行版重试稍后再试Linux 内无法解析域名/etc/resolv.conf被修改或失效cat /etc/resolv.conf设置generateResolvConftrue执行wsl --shutdownWindows 浏览器无法访问 WSL 内的服务端口.wslconfig中 localhostForwarding 被设为 false查看.wslconfig文件改为localhostForwardingtrue重启 WSLLinux 内脚本无法执行提示换行符错误使用了 Windows 编辑器修改 Linux 文件file script.sh查看类型用 VS Code Remote-WSL 编辑不要用记事本Linux 内文件权限全部变成 777在/mnt/c下创建文件时元数据无法完整保存ls -la /mnt/c/xxx把项目移到~/projects避免跨文件系统操作7. 日常使用和生产环境落地建议7.1 发布或迁移前的环境检查清单在把 WSL 环境用于正式项目之前建议先过一遍下面的检查清单系统版本为 Windows 10 2004 或更高WSL 已通过wsl --update更新到最新。两个 Windows 可选功能均已开启BIOS 虚拟化处于启用状态。wsl --list --verbose中目标发行版的 VERSION 列为 2。项目代码位于 Linux 文件系统例如~/projects不在/mnt/c。systemd 已开启需要常驻的服务能通过systemctl管理并设置开机自启。.wslconfig已限制内存和 CPU避免 WSL 抢占 Windows 资源。/etc/wsl.conf和~/.bashrc、~/.zshrc等配置已纳入 Git 仓库或做了备份。重要数据验证过备份恢复流程不依赖 WSL 本地的单一副本。7.2 扩展方向Docker、VS Code Remote-WSL 和本地 AI 工具WSL2 最常见的扩展是 Docker。Docker Desktop 在 Windows 上可以启用 WSL2 作为后端这样容器实际运行在 WSL2 的 Linux 内核里不需要再单独维护一台虚拟机。也可以在 WSL 发行版里直接安装 Docker Engine用 systemd 管理适合希望完全在 Linux 侧工作的团队。VS Code Remote-WSL 是另一种高价值组合。在 WSL 终端执行code .VS Code 会以远程方式连接当前 WSL 环境安装的插件、终端、调试器都运行在 Linux 侧避免了“Windows 编辑、Linux 运行”带来的换行符和路径问题。本地大模型推理工具也越来越多优先支持 Linux。想在本机实验 Ollama 这类工具时直接装进 WSL 比折腾 Windows 原生版更顺滑。这类工具普遍依赖 Linux 服务模型和 GPU 驱动透传WSL2 的兼容性已经接近真实 Linux 环境。7.3 仍然需要虚拟机或物理机的场景WSL 不是万能方案。下面这些场景仍然建议使用 VMware、VirtualBox 或物理机需要自定义 Linux 内核、编译内核模块、做内核崩溃调试。需要调整虚拟机的固件、网络模型、启动参数而 WSL2 由 Windows 托管难以深度定制。需要完整的 Linux 桌面环境并直接使用 USB 硬件直通。需要嵌套虚拟化实验例如在 Linux 虚拟机里再跑虚拟机。需要在一个干净、隔离、不共享 Windows 内存和网络的 Linux 环境里做兼容性测试。日常 Web 开发、脚本编写、中间件实验WSL 已经足够。但涉及系统级、硬件级实验时正确选择仍然是虚拟机或物理机。7.4 给新手的练习路径如果你刚接触 WSL建议按下面这个顺序练习而不是一上来就装各种工具安装 WSL 和 Ubuntu熟悉sudo apt update、sudo apt install的包管理流程。在~/projects下创建目录从 Windows 复制一个项目进去用 git 提交并跟踪变更。学写一个简单的 shell 脚本使用cron或 systemd timer 定时执行观察日志。在 WSL 里安装 Docker启动一个 Nginx 容器在 Windows 浏览器访问http://127.0.0.1:8080。把.wslconfig、/etc/wsl.conf、Shell 配置提交到自己的配置仓库形成可迁移的环境。WSL 出现后Windows 用户使用 Linux 的边界被重新划分了。日常开发不需要管理虚拟机就能在 Windows 上得到接近真实 Linux 的命令行体验。真正值得注意的是项目文件要放对位置WSL 版本要保持更新配置要做好备份把 WSL 当作一套需要维护的开发环境来对待。这样它才能在你需要的时候稳定可靠而不是在项目上线前突然给你添麻烦。