说实话，第一次接触 WSL 的时候我是不屑的。Windows 上跑 Linux？那不是虚拟机就是模拟器，图啥？直到我把本地的 Ubuntu 双系统扔掉，只在 Win11 里靠 WSL 写代码、跑 Docker、做模型推理以后，才意识到这东西早就不只是“玩具”了。WSL 的安装与运行，说难不难，一条 wsl --install 就能干完；说简单也真不简单，光我见过的报错就有十几种：下载太慢、403 禁止、WSL 版本太旧、matlab 识别不到 WSL、Docker Desktop 报 WSL 问题……每一句都能劝退一波人。这篇文章我就把这些年装 WSL 踩过的坑和验证过的方案从头到尾捋一遍，Windows 10 / 11 通用，从零把环境装好、跑起来，再给你一份日常配置清单和问题排查速查表。
1. WSL 到底是什么，为什么值得折腾
1.1 从“Windows 里跑 Linux”这件事说起
WSL 的全称是 Windows Subsystem for Linux，也就是 Linux 的 Windows 子系统。它不是一个普通的虚拟机，也不是把 Linux 整个搬到 Windows 里，而是微软专门做出来的一层“兼容层 + 轻量虚拟化”，让你能在 Windows 里直接运行 Linux 的命令行工具、编译器、脚本和大部分服务端程序。
为什么我建议开发者都装一个？因为大多数后端服务和 AI 生态里的依赖，都是先为 Linux 准备的。你在 Windows 上装 Python 库、编译 C 项目、跑 Redis、跑 Docker，多多少少会遇到路径分隔符、权限模型、动态链接库不兼容的怪问题；而 WSL 能让你在一个几乎原生的 Linux 环境里干活，同时又不用离开 Windows。它的文件系统可以和 Windows 互访，剪贴板、网络、本地端口都是通的，开发体验非常顺滑。
我见过不少新人把 WSL 和“装虚拟机”划等号，其实区别很大。虚拟机要单独安装系统、分配内存、占几个 GB 的磁盘，跑起来还要开图形界面；WSL 本质上是命令行优先的环境，启动速度是秒级，内存和 CPU 由 Windows 统一调度，你甚至感觉不到“里面还有一个系统”在跑。对于写代码、起服务、跑脚本这些日常任务，WSL 比虚拟机轻太多，也比双系统方便太多。
1.2 WSL1 和 WSL2，到底选哪个
聊安装之前，先把 WSL1 和 WSL2 的差别说清楚。
WSL1 是初代方案，做的是系统调用翻译，把 Linux 程序发出来的系统调用转换成 Windows 能理解的调用，所以它启动快、文件放在 Windows 目录下时读写速度也不错，但兼容性差一些，比如一些依赖 Linux 内核底层特性的程序就跑不了。
WSL2 则完全不同，它用的是真正的轻量虚拟机，内置一个完整的 Linux 内核。系统调用不再需要翻译，Linux 程序跑起来更接近真实的 Ubuntu 服务器。代价是跨文件系统读写会慢一点，启动时会占用一定内存。但绝大多数场景下，WSL2 的兼容性和稳定性都优于 WSL1，尤其是跑 Docker、CUDA、深度学习这类需要内核特性的应用，WSL1 基本带不动。
| 对比项 | WSL1 | WSL2 |
|---|---|---|
| 运行方式 | 系统调用翻译层 | 轻量虚拟机 + 完整 Linux 内核 |
| 启动速度 | 极快 | 快，秒级 |
| Linux 兼容性 | 一般，部分内核功能缺失 | 完整内核，兼容性更好 |
| 跨系统文件读写 | 较快 | 相对慢，建议常用文件放 Linux 侧 |
| 适合场景 | 简单命令、脚本测试 | Docker、CUDA、AI 工具链、服务端开发 |
所以我的建议很简单：没有特殊理由，一律选 WSL2。现在默认安装的 WSL 版本就是 2.x，你只需要在安装过程中留意一下，别让系统给你装个老版本就行。后面我会讲到怎么看当前版本，以及遇到太老版本时报错怎么处理。
2. 安装前的准备：先把这些条件补齐，后面少踩坑
2.1 系统版本、功能开关与虚拟化检查
很多人一上来就敲 wsl --install，然后卡在某个报错半天，最后发现是前置条件没满足。WSL 安装前，先确认三件事。
第一，系统版本。Windows 10 需要 2004 及以上版本，Windows 11 全版本基本都能装。查看方法是在运行框里输入 winver，然后回车，看系统版本号和内部版本号。太老的系统别急着装，先把系统更新跑完，否则后面每一步都可能出兼容问题。
第二，虚拟化功能。WSL2 依赖 CPU 的虚拟化能力和 Windows 的“虚拟机平台”组件。在任务管理器 -> 性能 -> CPU 里，可以看到“虚拟化”一栏是否显示“已启用”。如果没启用，需要先去 BIOS/UEFI 里打开 Intel VT-x 或 AMD SVM，这一步不做，后面装完 WSL2 也跑不起来。
第三，Windows 功能开关。在控制面板的“启用或关闭 Windows 功能”里，找到“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，确保打勾。如果你想用命令行，也可以直接在管理员 PowerShell 里执行：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart这两条命令第一个开 WSL 功能，第二个开虚拟机平台，执行完会提示重启。不要跳过重启，否则后续安装大概率失败。
2.2 确认基础命令是否就绪，避免装了重复环境
前置条件准备好之后，打开一个管理员身份的 PowerShell，先跑一句 wsl --status 看看当前状态。如果提示“Windows Subsystem for Linux 未安装”，说明功能没开或者系统还停留在很老的版本。如果提示“wsl 不是内部或外部命令”，基本可以判断系统版本过老，或者功能开关没生效。
在这个阶段，还要决定你到底需要装哪个发行版。大多数教程默认是 Ubuntu，这也是最主流、文档最多的选择。网上很多问题反馈里提到的“wsl ubuntu 写代码”“wsl 安装 ubuntu”，用的基本都是 Ubuntu 22.04 / 24.04。如果你只是日常开发，我建议选 Ubuntu 22.04 LTS，原因很简单：教程多、软件源里的依赖稳定、遇到报错随便一搜就有答案。如果你要跑一些 AI 项目，很多模型推理工具链也是优先适配 Ubuntu 平台，选这个版本最省心。
3. 安装过程全记录：从 wsl --install 到 Ubuntu 落地
3.1 一键安装：wsl --install 的正确姿势
环境准备无误后，在管理员 PowerShell 里执行：
wsl --install这条命令是微软官方推荐的一站式安装方式。它会自动完成三件事：启用需要的 Windows 功能、下载并安装最新版 WSL 运行组件、把默认发行版（通常是 Ubuntu）装好。整个过程比老方法要省事得多，不需要你去“启用或关闭 Windows 功能”里手动勾选，也不需要专门从商店里搜 Ubuntu。
如果你不想用默认发行版，可以先查看有哪些可选：
wsl --list --online执行之后会列出当前可用发行版的名字，比如 Ubuntu-22.04、Ubuntu-24.04、Debian、kali-linux 等。选好之后用下面的命令指定安装：
wsl --install -d Ubuntu-22.04装完系统会提示你需要重启。重启之后，首次启动 Ubuntu 会让你设置用户名和密码，到这里，WSL 的安装就算完成了。整个过程如果网络畅通，十分钟内就能搞定。
3.2 安装慢、卡在“正在下载”的三种有效解法
wsl --install 这条路虽然简单，但不少人会卡在“正在下载”或“正在安装: Ubuntu”那一行，半天不动弹。热词里相关的高频反馈也很多，比如“wsl --install 太慢”“wsl --list --online 连接超时”。这通常是发行版镜像下载不稳定导致的，不是命令本身出了问题。
针对这种卡顿，我验证过下面几种处理思路，按优先级从高到低给新手参考。
第一种，更新 WSL 后重试。旧版 WSL 的发行版安装往往走的是商店通道，容易和商店下载服务互相干扰。先在管理员 PowerShell 里执行 wsl --update，把它升到比较新的版本，然后再运行 wsl --install -d Ubuntu-22.04。我实际测下来，新版 WSL 的下载逻辑更稳定，卡住的概率低很多。
第二种，换个网络环境或者换 DNS。比如把 DNS 暂时改成 223.5.5.5 这样的公共 DNS，刷新之后重新执行安装命令。有时候纯粹是域名解析到某个慢节点，换一下就好了。
第三种，干脆放弃在线安装，走离线包方案。这个方法对“wsl --install 卡死”“商店下载不动”的情况最有效，尤其是长期企业版这类系统，商店组件不完整时，离线包几乎是唯一解。具体步骤我放到 3.3 节详细说。
3.3 离线安装 Ubuntu：适合内网和老系统
离线安装的核心思路是：不依赖 wsl --install 或商店，直接把 Ubuntu 的发行版镜像文件下到本地，手动注册到 WSL 里。
准备阶段，你需要拿到 Ubuntu 的安装包。比较靠谱的来源是微软官方渠道。你可以在一台网络正常的 Windows 机器上，用 wsl --export 导出一个已有的发行版备份，也可以从微软官方提供的链接下载 Ubuntu appx 包。拿到安装包之后，用 PowerShell 执行：
Add-AppxPackage .\Ubuntu.appx这个命令会把 Ubuntu 注册到系统里，然后你就能在开始菜单里找到 Ubuntu 图标，第一次打开会进入初始化设置。如果系统不支持商店打包的应用，还有一个更通用的办法：把 appx 包改成 zip 后缀，解压后直接运行里面的 ubuntu.exe。
如果你拿到的不是 appx，而是 .wsl 或 .tar 的根文件系统文件，那就用 wsl --import 命令：
wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 ubuntu-22.04.tar --version 2这里的三个参数分别对应发行版名称、安装目录、镜像文件路径。--version 2 表示安装为 WSL2 发行版。
需要提醒的是，用 import 方式导入的发行版不会自动创建默认用户，进去之后就是 root。想要恢复成自己平时的账号，需要手动修改 /etc/wsl.conf 或在发行版里执行命令指定默认用户。这个细节很多人会忽略，后面 4.1 节我再展开讲。
离线安装最怕下错包，所以一定要从可信来源下载，别贪方便用来源不明的压缩包。装完之后用 wsl --set-default Ubuntu-22.04 把默认发行版改一下，下次打开 WSL 就直接进你想要的环境。
4. 装完之后的初始化与日常使用配置
4.1 用户、默认发行版、root 登录与 .wslconfig 资源限制
第一次启动 Ubuntu，系统会让你输入一个用户名和密码。这个用户名是普通用户，自带 sudo 权限，日常操作用它就够了。如果你需要 root，可以直接运行：
wsl -d Ubuntu-22.04 -u root在 Windows 里把默认发行版和默认用户固定下来也很重要。常用命令：
wsl --set-default Ubuntu-22.04 wsl --set-default-version 2默认用户如果不是 root，想在 Windows 终端里直接以 root 身份进系统，可以在发行版内编辑 /etc/wsl.conf，加上：
[user] default=root然后 wsl --shutdown 重启一下 WSL 就能生效。
除了用户，资源限制是 WSL2 最容易忽略的地方。默认情况下 WSL2 会占用你一半的内存，如果你机器只有 16GB 而且还要跑 Docker、VSCode、浏览器，很容易卡。这时候可以在用户目录下建一个 .wslconfig 文件，内容参考这样：
[wsl2] memory=6GB processors=4 swap=2GB localhostForwarding=truememory 是分配给 WSL 的最大内存，processors 是 CPU 核数，swap 是交换分区大小。配置完执行 wsl --shutdown，重新启动 WSL 才会生效。我实际用下来，设成 6GB 左右对大多数开发任务都足够，既不会 Windows 卡，也不会 WSL 卡。
4.2 VSCode 与 PyCharm 接入 WSL 的工作流
装好 WSL 之后，很多人第一件事就是在 VSCode 里写代码。VSCode 的官方 WSL 扩展是最成熟的方案：先在 Windows 侧装好 VSCode，再安装扩展“WSL”。然后在 WSL 终端里进入你的项目目录，执行：
code .VSCode 会自动切换成远程开发模式，在窗口左下角显示 WSL: Ubuntu-22.04 之类的标识。这个模式下的终端、调试器、语言服务器都跑在 Linux 环境里，体验和直接在 Ubuntu 里写代码几乎没区别。你在 Windows 的 VSCode 里装的扩展是独立的，WSL 里的扩展需要在 WSL 环境中单独安装，第一次打开提示“Install in WSL”时点一下就行。
PyCharm 用户也有接入方案。社区版和专业版都支持通过 WSL 解释器来跑项目。操作路径是：Settings -> Project -> Python Interpreter -> Add Interpreter -> WSL，然后选择 WSL 发行版和你装的 Python 路径。如果你在 WSL 里装了 conda，可以在 WSL 的终端里运行 conda env list 找到环境路径，然后填进去。这样 Windows 下用 PyCharm 写代码，实际执行环境在 WSL 里，依赖不会冲突，也不用在 Windows 里复制一份开发环境。
4.3 终端字体与体验调整：接近 macOS 的编码感受
从 Mac 切到 Windows 的朋友经常会觉得默认终端难看，字距发虚，配色刺眼。我推荐三个组合改进，让 WSL 终端观感尽量接近 macOS 那种干净清爽的体验。
第一，把默认终端换成 Windows Terminal。Windows 11 自带了，Windows 10 也可以从商店装。它的字体渲染、多标签、快捷键都比老式 conhost 好太多。
第二，换字体。Windows Terminal 的设置里可以把字体设为 Cascadia Code 或 JetBrains Mono，这两款都是等宽字体，符号覆盖全，写代码时对得很齐。如果日常要显示中文注释，建议用更纱黑体等宽版或类似的中文等宽字体，避免中英文字宽不一致导致代码对不齐。
第三，装一套 zsh + oh-my-zsh。WSL 里默认是 bash，功能不差，但 zsh 的补全和主题更现代，配合插件之后效率高不少。安装命令很简单：
sudo apt install zsh sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" chsh -s $(which zsh)装好后把 Windows Terminal 的默认 shell 切到 zsh，再配一个喜欢的主题，日常编码的舒适度能提升一个档次。这一套组合下来，我身边几个从 Mac 转 Windows 的同事都说，至少在终端体验上已经没什么不习惯了。
5. 常见问题与排查技巧实录
5.1 wsl --update 慢、403 报错怎么破
先解释一下 wsl --update 是在干嘛。新版 WSL 把运行组件改成了独立安装包，更新动作会从远端服务器拉取新的 WSL 组件。因为这个下载源跨地域访问不稳定，经常会出现下载慢，甚至返回 403 禁止访问的问题，报错内容类似“wsl --update 已禁止(403)”。
遇到这种问题，优先做三件事：第一，确认用的是管理员 PowerShell；第二，多试几次，403 很多时候是偶发的连接问题，换个时间再更新可能就好了；第三，检查系统时间是否正确，时间不对会导致 TLS 握手失败，返回莫名的错误码。
如果重试还是不行，就换用手动更新。去微软官方文档找 WSL 的更新安装包，下载 msi 或 msix 后双击安装。安装完在 PowerShell 里执行 wsl --version，能看到版本号就说明更新成功了。这个方式的优点是完全绕开在线更新通道，缺点是版本可能比在线方式新得慢一点，不过用来解决“版本太旧”这类问题已经够用。
5.2 “WSL 版本太旧”提示的内核更新
很多人在装 Docker Desktop 或者是跑 wsl --install 时会看到这样一句提示：your version of windows subsystem for linux (wsl) is too old. run the command wsl --update。意思是当前 WSL 组件版本太老，需要更新到新版本才能继续。
这种提示在 Windows 10 的某些长期服务版本上特别常见。解决办法就是先执行 wsl --update，如果更新过程卡住或报错，就按 5.1 节的手动更新方式处理。另外，也可以在 PowerShell 里查一下当前 WSL 的版本：
wsl --version如果命令提示不认识 --version 参数，说明你的 WSL 还是非常老的“内核组件包”形式，这时候建议先把 Windows 系统更新补丁打全，再执行 wsl --update。老版本 WSL 的内核和运行组件是分开存在的，升级后一般会自动切换到新版架构。
内核版本的另一种查看方式，是在 WSL 终端里运行 uname -r，输出的是 Linux 内核版本。如果这个版本号很低，比如 4.x、5.4 这种老内核，那也说明 WSL2 的内核没升级到位，同样需要 wsl --update 或手动装新内核包。
还有一个经常被问到的场景是“matlab 识别不到 wsl”。多半就是 WSL 组件版本太老，matlab 拿不到可用的 Linux 环境接口。先把 wsl --update 跑完，再重新打开 matlab，通常就能在环境列表里看到 WSL 选项。
5.3 网络类报错：连接远程计算机失败、超时
WSL 相关的网络问题非常多，下面几条是最常碰到的。
第一种，wsl --list --online 连接超时。这条命令用来列出远程可用发行版，如果网络不稳定就会卡住或直接超时。解决办法是可以不去执行它，直接在安装命令里写死发行版，比如 wsl --install -d Ubuntu-22.04，跳过列表查询这一步。
第二种，重启 WSL 后 VSCode 或 Docker 连不上 WSL。这通常是 WSL 内部网络服务没起来，或者 DNS 配置异常。先执行 wsl --shutdown，停掉所有 WSL 发行版，再重新打开终端，一般就能恢复。
第三种，WSL 里访问外部网络正常，但 Windows 里的程序访问 WSL 里的服务失败。这个要看端口和防火墙。WSL2 默认支持 localhostForwarding，你把服务监听在 0.0.0.0 或 localhost，Windows 这边通过 localhost 端口基本都能访问。如果不行，检查一下 Windows 防火墙是否拦截了对应端口。
第四种，提示“wsl 计算机无法连接到远程计算机”。这类报错常见于 VSCode Remote 或某些需要 TCP 连接的开发插件。排查时先确认 WSL 内部服务有没有起来，再用 curl 或 telnet 测一下目标端口。很多时候是服务监听地址写成了 127.0.0.1，改成 0.0.0.0 就通了。
我给新手一个通用排查顺序：先 wsl --shutdown 重启环境，再检查 DNS 和端口，最后看防火墙规则。大多数网络问题在这三步里都能找到答案。
5.4 卸载不干净的问题与重装建议
WSL 卸载不干净，通常是因为只删了发行版，没有删组件，或者反过来。我建议按下面的顺序操作，能清理得比较彻底。
第一步，停掉 WSL。
wsl --shutdown第二步，注销发行版。这个操作会删除该发行版内部的所有数据。
wsl --unregister Ubuntu-22.04第三步，如果你连 WSL 组件也想卸载，可以在 Windows 设置 -> 应用里找“Windows Subsystem for Linux”并卸载。如果找不到，就用管理员 PowerShell 关掉两个功能开关：
dism.exe /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux /norestart dism.exe /online /disable-feature /featurename:VirtualMachinePlatform /norestart重装之前，如果你只是想换个发行版或者迁移到另一个盘，先用 wsl --export 导出备份，再把备份用 wsl --import 导入新目录，这样数据不会丢。我见过太多人卸载前想起来要备份，已经来不及了，所以只要你的某套环境配了很久，第一步永远是导出。
| 症状 | 可能原因 | 处理方法 |
|---|---|---|
| wsl --install 卡住 | 发行版下载不稳定 | 更新 WSL、换 DNS、用离线包 |
| wsl --update 403 | 更新下载源连接异常 | 重试、手动装更新包 |
| 提示 WSL 版本太旧 | WSL 组件过老 | wsl --update 或手动更新内核 |
| Docker 报 WSL 问题 | WSL 状态异常或版本过旧 | wsl --shutdown、wsl --update |
| 网络连接失败 | DNS/防火墙/端口监听 | 重启 WSL、检查监听地址和防火墙 |
6. 安装后的扩展玩法：把 WSL 当主力开发环境
6.1 Docker Desktop 与 WSL2 的联动
WSL 装好之后，最值得配置的扩展就是 Docker Desktop。Docker 的 Windows 版现在默认使用 WSL2 作为后端，意思是你不用再维护 VirtualBox 或 Hyper-V 的单独虚拟机，Docker 引擎直接跑在 WSL2 的轻量虚拟机里。
安装完 Docker Desktop，进入 Settings -> Resources -> WSL Integration，确保勾选了对应的 WSL 发行版，然后在 WSL 终端里验证：
docker version能输出 Docker 版本信息就说明联动成功。Docker 配 WSL2 的优势在于，Windows 和 WSL 里的 docker 命令操作的是同一个引擎，你可以在 Windows 的终端里敲 docker ps，也可以在 WSL 里敲 docker ps，结果完全一致。很多人在 Windows 里跑 Redis、MySQL、Nginx 都是直接用 Docker，省去了本地编译安装的一大堆麻烦。
如果 Docker Desktop 启动时报“there was a problem with wsl”，通常就是 WSL 组件版本太旧或者发行版状态异常。处理方式很简单：wsl --update 更新组件，wsl --shutdown 重启 WSL，然后再打开 Docker Desktop。这条命令顺序我建议记住，一年能帮你省下不少排查时间。
6.2 WSL 里的 CUDA 配置（GPU 加速）
如果你要在 WSL 里跑深度学习模型推理，或者做一些 GPU 相关的计算，CUDA 配置是关键。好消息是 WSL2 对 GPU 的支持非常完善，Windows 侧的 NVIDIA 驱动可以直接被 WSL 内部访问，你不需要在 WSL 里再装一遍显卡驱动。
用 nvidia-smi 可以确认驱动是否可见。如果命令没找到，升级一下 Windows 侧的 NVIDIA 驱动，尽量用支持 WSL 的新版本。接下来装 CUDA Toolkit。打开 WSL 终端，执行：
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt update sudo apt install cuda-toolkit安装完把 CUDA 的 bin 目录加到 PATH 里，然后重新打开终端，执行 nvcc --version 验证。整个过程最需要注意的是 CUDA 版本和显卡驱动版本的兼容性，如果驱动太老，新版本 CUDA 可能装得上但跑不起来。建议先查一下驱动支持的 CUDA 版本，再选择合适的 toolkit 版本安装。
6.3 常用工具与项目部署示例：binwalk、redis、AI 工具链
装好 WSL 之后，很多平时在 Linux 上才能折腾的工具都能直接跑。比如固件分析工具 binwalk，在 WSL 里一条命令就能装好：
sudo apt update && sudo apt install binwalkbinwalk 常用来扫描固件、提取文件系统，配合 foremost 做文件恢复也很顺手。再比如 Redis，如果你只是想在本地调试，直接 apt 安装最简单：
sudo apt install redis-server redis-server --daemonize yes如果要模拟生产环境，就用 Docker 跑一个 Redis 容器，配置和数据卷都更好控制。
另外，不少 AI 相关的开源项目，文档里都建议在 Linux 环境里跑，WSL 往往就是 Windows 用户最顺手的落地点。像 codex、deep seek harness、moss-vl 这类工具，在 WSL 里跑，依赖安装逻辑和真实服务器保持一致，减少大量“Windows 环境特有”的兼容问题。我的经验是，凡是文档第一页写着“Linux/macOS only”的项目，先默认丢进 WSL 跑，基本不会错。
7. 我的一些个人心得与建议
折腾 WSL 这几年，我最大的感受是：这东西的安装本身不难，难的是“装完之后怎么让它真正融进你的日常开发”。如果只是装完拍个照片，那它和一个虚拟机没什么区别；但如果你把 VSCode、PyCharm、Docker、CUDA 这些全部接到 WSL 上，Windows 就从一个“勉强能写代码的系统”变成了一个“能跑全栈开发环境的主机”。
给新手的建议是：第一次安装尽量走标准流程，遇到问题先别急着重装系统，按 3.2 节的思路换更新、换网络、换离线包，大多数情况都能解决。日常使用中，养成“用完就 wsl --shutdown”的习惯，能把内存占用降到最低。另外，发行版的虚拟磁盘文件默认放在 C 盘，装的东西多了 C 盘会越来越小，建议用 wsl --export / --import 把发行版迁到数据盘，这一步能省掉很多磁盘告急的麻烦。
如果你现在还在犹豫要不要装 WSL，我的答案是直接装。不用放弃 Windows，也不用学习完整的 Linux 运维，只需要会用几条命令，就能拿到一个随时可用的 Linux 开发环境。这种投入产出比，在开发工具里真的不多见。
