不用虚拟机，也能在 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 电脑，给虚拟机分 4GB，Windows 就只剩 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、不需要安装 VMTools，Windows 会在需要时自动启动这个运行环境。
这里要澄清一个容易误解的点：标题说“不用虚拟机”，指的是用户不需要自己搭建和维护虚拟机。WSL2 在底层确实借用了轻量虚拟化技术，但它与传统虚拟机的管理体验完全不同。用户面对的是一个普通终端，Windows 负责管理内核启动、内存回收和磁盘生命周期，而不是让你去配置一台“机器”。
1.3 WSL1 和 WSL2 的选择依据
虽然新版本默认推荐 WSL2，但了解两者的差异仍然很重要，因为某些老机器或特殊场景下 WSL1 反而更合适。
| 对比项 | WSL1 | WSL2 |
|---|---|---|
| 系统调用兼容性 | 翻译层实现，部分复杂调用不兼容 | 真实 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 11 | wsl --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 还是 WSL2：
wsl --list --verbose输出中的VERSION列如果是2，说明已经在使用 WSL2。如果是1，需要把默认版本切换成 WSL2：
wsl --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/c，D:盘对应/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] systemd=true [user] default=zhangsan [network] generateResolvConf=true [interop] enabled=true appendWindowsPath=true [automount] enabled=true options="metadata,umask=22,fmask=11"各段含义如下：
[boot] systemd=true：让 WSL 使用 systemd 作为系统初始化程序，这样才能用systemctl管理服务。[user] default=zhangsan：指定进入 WSL 后默认登录的用户。如果忘了设置，每次进入会是默认用户，可能不是自己创建的那个用户。[network] generateResolvConf=true：让 WSL 自动生成/etc/resolv.conf。如果这个值为false，常会导致 Linux 内无法解析域名。[interop]：控制是否允许从 Linux 调用 Windows 程序，以及是否把 Windows PATH 追加进来。日常开发保持enabled=true。[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] memory=4GB processors=4 swap=4GB localhostForwarding=true| 参数 | 含义 | 常见值 | 错误配置的表现 |
|---|---|---|---|
| memory | WSL2 最多可用的内存 | 4GB 或 8GB | 设置过高会使 Windows 侧内存紧张，系统卡顿 |
| processors | WSL2 最多可用的 CPU 核数 | 2 到 4 | 设置过高会影响 Windows 前台应用的响应速度 |
| swap | WSL2 使用的交换文件大小 | 与内存相当或略大 | 设置过小，内存不足时会出现 OOM 杀进程 |
| localhostForwarding | Linux 内监听端口是否映射到 Windows 的 127.0.0.1 | 默认 true | 设为 false 后，Windows 浏览器无法访问 WSL 里的服务端口 |
这里的核心思考是：WSL2 作为一个轻量虚拟机，内存分配是受限的。如果不写memory，WSL2 可能会按宿主机内存的一定比例占用，机器内存较小时会影响 Windows 自身。如果是 16GB 内存的机器，给 WSL2 分配 4GB 是一个稳妥起点；如果是 32GB，可以分到 8GB。
修改.wslconfig后同样需要wsl --shutdown才能生效。
5.3 systemd 开启后的变化
早期 WSL 不提供 systemd，用户无法用标准的systemctl管理服务，安装 Docker 后只能手动执行dockerd，体验和真实 Linux 差别很大。现在 WSL 已经支持 systemd，在/etc/wsl.conf里开启systemd=true后，就能获得接近真实服务器的服务管理体验。
开启后，安装并启动 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 或 0x80070003
0x8007019e 常见于 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 虚拟化确实无法开启，兼容方案是把该发行版降级回 WSL1：
wsl --set-version Ubuntu 1WSL1 不依赖虚拟机平台，但功能会比 WSL2 少一些。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 检查方式 | 处理建议 |
|---|---|---|---|
wsl命令无法识别 | WSL 未安装或环境变量异常 | where wsl | 管理员 PowerShell 执行wsl --install |
| 安装发行版一直卡在下载 | 网络不稳定，下载中断 | 观察下载进度是否长时间不动 | 更换发行版重试，稍后再试 |
| Linux 内无法解析域名 | /etc/resolv.conf被修改或失效 | cat /etc/resolv.conf | 设置generateResolvConf=true，执行wsl --shutdown |
| Windows 浏览器无法访问 WSL 内的服务端口 | .wslconfig中 localhostForwarding 被设为 false | 查看.wslconfig文件 | 改为localhostForwarding=true，重启 WSL |
| Linux 内脚本无法执行，提示换行符错误 | 使用了 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 当作一套需要维护的开发环境来对待。这样它才能在你需要的时候稳定可靠，而不是在项目上线前突然给你添麻烦。
