如果你在 Windows 上做开发，迟早会碰到 WSL 这个东西。它全称 Windows Subsystem for Linux，简单说就是让 Windows 系统直接跑一个 Linux 环境，不用装虚拟机、不用搞双系统、不用关机重启。我第一次接触 WSL 是好几年前做前端项目部署，当时在 Windows 命令行里折腾 shell 脚本、路径分隔符和权限问题，差点想把电脑砸了。后来装上 WSL，把部署脚本、Docker、Linux 工具链全部挪进去，Windows 做日常桌面，Linux 做开发环境，两个系统打通着用，舒服得不是一点半点。这篇文章我就从 WSL 的下载安装讲起，覆盖在线安装、离线安装、网络慢、版本报错、VS Code 连接、CUDA 深度学习、本地大模型部署这些常见场景。新手照着做就能把环境跑起来，老手可以直接跳到问题排查章节捡点干货。
1. 安装前的必修课：先搞清楚 WSL 是什么，WSL1 和 WSL2 怎么选
1.1 WSL 不是虚拟机：它是一个跑在 Windows 里的 Linux 兼容层
WSL 全名 Windows Subsystem for Linux，本质上是微软在 Windows 内核里提供的一个 Linux 兼容层。WSL1 的做法是把 Linux 系统调用翻译成 Windows 系统调用，所以它没有自己独立的 Linux 内核；WSL2 则是把完整 Linux 内核装在一个轻量级虚拟机里，由 Windows 自带的 Hyper-V 虚拟化平台托管。两种方案各有特点，但共同点是：你不需要自己装 VMware、VirtualBox，也不需要在开机引导界面里切换系统，启动一个 Ubuntu 基本就是一秒进终端。
为什么开发环境特别适合放 WSL？因为服务端工具链，比如 apt、systemd、nginx、Redis、Python 的 lxml 编译、交叉编译工具等，在原生 Linux 上踩坑最少。Windows 上要么缺依赖，要么路径分隔符折磨人，要么编译环境不齐全。把 Linux 环境装进 WSL 之后，你可以在 Windows 桌面环境里写文档、聊天、做设计，终端窗口里却是一个完整的 Ubuntu，两边互不干扰。
这里要特别纠正一个误区：WSL 不等于“Windows 虚拟机”。默认情况下它没有图形桌面，你看到的是纯命令行交互；它更接近一个“命令行 Linux 子系统”。实际使用中 WSL 和 Windows 之间的文件交互是通过\\wsl$路径完成的，性能上有取舍，后面我会专门讲文件存放位置的问题。你可以把它理解成 Windows 系统里的一个“特殊容器”，但它比容器更底层，启动更快，和 Windows 的集成也更紧密。
1.2 WSL1 和 WSL2 到底怎么选：一张表看懂差异
| 维度 | WSL1 | WSL2 |
|---|---|---|
| 内核 | 翻译层，没有 Linux 内核 | 完整 Linux 内核，跑在轻量级虚拟机里 |
| 系统调用兼容性 | 有部分限制，复杂内核模块不可用 | 几乎完全兼容，支持 Docker 后端 |
| 跨文件系统访问 | 通过 Windows 盘符读写文件较快 | 跨文件系统访问较慢，Linux 原生文件系统快 |
| 启动速度 | 极快 | 很快，通常 1~2 秒 |
| 内存占用 | 低 | 有虚拟机开销，但可以用配置限制 |
| 适合场景 | 简单命令、脚本、快速文件访问 | Docker、数据库、深度模型、依赖内核特性的软件 |
现在新装系统直接默认 WSL2 就好。WSL1 唯一还值得用的场景，是你需要频繁访问 Windows 盘符下的文件，比如在C:\projects里跑一个小脚本，项目代码就放在 Windows 分区，WSL1 的跨文件系统性能反而更好。但如果你要跑 Docker 或者安装需要内核模块的软件，WSL2 几乎是唯一选择。我的建议很直接：没有特殊需求，无脑选 WSL2，省得以后遇到兼容性问题再折腾迁移。
1.3 安装前必须做的检查：系统版本、虚拟化开关、功能组件
安装 WSL2 需要 Windows 10 2004 以上，或者 Windows 11。如果你用的是 Windows Server，一般要 2019 以上且开启虚拟化，不过家用和办公场景还是以 Win10/Win11 为主。检查方法很简单，按Win+R输入winver看版本号就行。老版本系统也能装 WSL1，但没必要，建议先把系统更新推到最新再动手，能少踩不少坑。
WSL2 依赖 CPU 虚拟化。你可以在任务管理器“性能”页签里看“虚拟化”是否显示“已启用”，或者用管理员 PowerShell 跑systeminfo，在“Hyper-V 要求”部分看四个项目是否都是“是”。如果显示“固件中已启用虚拟化”为“否”，需要进 BIOS 打开 VT-x（Intel）或 SVM（AMD）。这一步卡住不少人：电脑明明很新，装 WSL 却一直提示“请启用虚拟机平台”，最后发现是 BIOS 里的虚拟化开关没开。
还要确认你是用管理员权限打开的 PowerShell。大部分 WSL 装不上都和三个前置条件有关：系统版本不够、虚拟化没开、功能组件没启用。不要一看到报错就想着重装系统，先把这三样排查完再说。
2. 从零开始下载安装 WSL：官方最快路径与离线方案
2.1 一条命令装完：wsl --install 的完整流程
最省事的路径，是在管理员 PowerShell 里敲：
wsl --install这条命令会自动启用VirtualMachinePlatform和Microsoft-Windows-Subsystem-Linux两个 Windows 功能，默认安装 Ubuntu 发行版，最后提示重启。重启之后系统会要求你设置 Linux 用户名和密码。注意这个用户名可以和 Windows 用户名不一样，密码只在sudo和部分服务登录时用到，后面可以随时改。整个过程大概五到十分钟，如果网络好可能更快，比手动开功能、下安装包、配环境要省心得多。
有的机器会自动装好 WSL2 内核更新包，有的老系统不会。重启后如果提示内核太旧，先跑wsl --update更新；如果还报错，就按这篇文章 3.1 节里的方法手动下载 MSI 包。另外，wsl --install -d Debian可以指定装别的发行版，比如 Debian、Kali Linux，不一定非得 Ubuntu。
这里有个细节值得提醒：默认的wsl --install会把发行版安装在 C 盘用户目录下，装完就占用几个 GB 空间。如果 C 盘紧张，不用急，后面我会讲导出导入发行版到其他盘的方法。不要一开始为了省空间把安装路径改到乱七八糟的地方，先用默认路径把环境跑通最重要。
2.2 手动安装流程：老方法依然有效，适合被组策略限制的电脑
如果你是公司电脑，IT 策略限制了 Microsoft Store，或者wsl --install因为某些原因装不上，手动流程仍然管用。第一步，用管理员 PowerShell 执行两条命令启用功能：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启电脑。第二步，去微软官网下载 WSL2 内核更新包，找一个名称为“x64 用户 WSL2 Linux 内核更新包”的 MSI 文件，下载后双击安装。第三步，在 PowerShell 里执行：
wsl --set-default-version 2确保后续安装的发行版默认使用 WSL2。第四步，去 Microsoft Store 搜索 Ubuntu，或者用网页打开商店链接安装。
这套流程看起来比一条命令多几倍，但每一步都能看见执行结果，出问题容易排查。我在公司老笔记本上被组策略挡着没办法用商店时，就是靠这段流程装成功的。对于想搞清楚 WSL 到底装了什么的人来说，手动走一遍也能对系统改动有更清楚的认识。
2.3 安装太慢或者卡住怎么破：换源、离线包、web-download
“wsl install 太慢了”是高频问题，尤其是通过wsl --install下载发行版时，进度条经常卡在 0 或者百分之几。先判断是哪个环节慢：如果功能启用正常、重启后进入发行版安装阶段卡住，大概率是 Microsoft Store 的下载通道不给力；如果你执行命令后一直停在“正在下载”的字样，那也多是下载通道的问题。
我的处理顺序是这样。第一步，先给wsl --install加一个--web-download参数试试：
wsl --install -d Ubuntu --web-download这个参数会绕过商店组件下载，改用 WebView 下载机制，很多卡 Store 的人用这一招直接就通了。第二步，如果还慢，直接走离线包路线：去微软商店对应的 Ubuntu 页面下载.appx或.msixbundle安装文件，这个文件通常几百 MB，下载完放到本地目录，然后执行：
Add-AppxPackage -Path ".\Ubuntu.appx"安装完成以后，从开始菜单里启动 Ubuntu 图标，或者执行wsl -l -v看发行版是否注册成功。第三步，离线包也能通过发行版 rootfs 压缩包配合wsl --import导入，具体见 5.3 节。总之不要干等，几十 KB/s 的下载速度下几个 GB 谁也扛不住。装完发行版之后，如果想改善 apt 下载速度，就去编辑/etc/apt/sources.list，把 Ubuntu 官方源换成国内镜像源，这一步新手建议尽早做，后面装软件会快很多。
2.4 多发行版共存：默认版本切换和资源限制
WSL 可以同时装好几个发行版。用wsl -l -v能看到当前机器上的所有发行版以及它们的 WSL 版本状态，用wsl -d Ubuntu-24.04可以指定进入某个发行版。想让某个发行版成为默认，不写-d直接敲wsl就是进入它，切换命令是：
wsl --set-default Ubuntu-24.04多发行版并存时最需要注意的是内存和磁盘占用。每个发行版都有独立的 rootfs，内核是共享的。如果你同时跑 Ubuntu 和 Kali，Windows 会为它们各自分配内存，最好在%UserProfile%\.wslconfig里写清楚上限，比如：
[wsl2] memory=8GB processors=4改完执行wsl --shutdown再启动才生效。很多人以为多装几个发行版会导致磁盘爆炸，其实去C:\Users\你的用户名\AppData\Local\Packages下看看发行版包目录，就能找到空间去向。.wslconfig 是 WSL2 的全局配置入口，掌握它以后，内存吃紧、CPU 占用过高等问题都能在这里解决。
3. 避坑指南：装完最容易遇到的几个报错和解决方法
3.1 打开就提示 wsl needs updating / WSL 版本太旧怎么办
这是遇到频率极高的一条。窗口弹出“Your version of Windows Subsystem for Linux (WSL) is too old”或者类似英文提示，意思是当前 WSL 组件版本太老，不满足发行版运行要求。这不是你操作错了，而是系统自带的 WSL 组件确实太旧，需要单独更新。
解决方法分两步。先执行：
wsl --update如果这条命令能正常跑完，问题就解决了。如果提示无法更新，或者更新后仍然报错，就去微软官方 WSL 发布页面手动下载最新的 WSL 安装包（MSI 格式），双击安装后重新打开终端。这里要强调一下：WSL 现在已经改成通过独立分发的软件包更新，不再跟着 Windows 大版本一起更新，所以不要觉得“我系统是最新的”就没问题，必须单独看 WSL 版本。用wsl --version可以查看当前版本号。
更新完之后记得执行wsl --shutdown，把后台所有 WSL 实例停掉再启动。WSL 这一类问题很多都能靠这个命令解决，它相当于整个子系统的“重启大法”。如果你开了好几个终端窗口，改完配置后不生效，多半就是旧实例没有被真正终止。
3.2 Ubuntu 启动卡住、WSL 无法连接服务器
现象一：双击 Ubuntu 图标后，窗口一直卡在加载界面没反应。优先执行wsl --shutdown把所有实例关掉，再重新打开。如果还卡，检查%UserProfile%\.wslconfig里是不是把memory写得太大或太小，改到 4GB 到 8GB 之间再试。另一个常见原因是 Windows 更新后 Hyper-V 服务状态不对，去“服务”里确认Hyper-V Host Compute Service正在运行。
现象二：WSL 里ping不通外网，apt 更新报“无法连接服务器”。WSL2 默认走 NAT 网络，Windows 侧网络环境一变，DNS 或虚拟交换机可能没跟着更新。先查看/etc/resolv.conf里的 nameserver 是否可用，如果不可用，把它改成国内常用 DNS 地址；再手动编辑/etc/wsl.conf，在[network]段里加上generateResolvConf = false，防止每次启动覆盖配置。改完执行wsl --shutdown重启。
这里要提醒：WSL2 的网络和 Windows 用的不是同一套 IP。如果你在 WSL 里启动了一个服务，想让 Windows 浏览器访问，直接访问localhost就行，因为 WSL2 默认有 localhost 转发机制。但如果你想让局域网里其他设备访问，就不能直接填 WSL 的 IP，端口转发和防火墙规则需要单独配。这一块很多人第一次搞会觉得很绕，记住“Windows 访问 WSL 用 localhost，外部设备访问 Windows 的端口再转进去”就好。
3.3 端口被占用怎么杀：Windows 和 WSL 两端的方法
开发的时候端口冲突最烦人。比如 Redis 默认 6379、Elasticsearch 默认 9200，经常一启动就提示“端口已被占用”。Windows 侧的做法是，先用下面命令找到占用端口的进程：
netstat -ano | findstr :6379最后一列是 PID，然后执行：
taskkill /F /PID 1234WSL 内部同理，用ss -tlnp或lsof -i :6379找到 PID 再kill -9。需要说明的是，有时候 WSL 里显示端口没被占，但 Windows 启动还是报错，这是 Windows 侧有一个残留进程占着端口。所以在 WSL 里跑数据库之前，先在 Windows 侧把报错提示里的端口查一遍，两边都不冲突才算干净。
端口问题还有一个隐蔽来源：Hyper-V 保留端口范围。Windows 会为 Hyper-V 保留一批随机端口，如果你的应用端口恰好落在保留段里，就会出现“明明没进程占用但端口就是绑不上”的情况。用以下命令查看保留范围：
netsh interface ipv4 show excludedportrange protocol=tcp如果 6379、9200 落在保留段里，要么换端口，要么碰碰运气执行net stop winnat再net start winnat。这个坑很冷门，我遇到过一次，排查了半个多小时才找到原因，遇到端口绑定失败时记得往这个方向查。
3.4 PowerShell 脚本闪退、命令执行策略问题
有的朋友在 Windows 侧写 .ps1 脚本，双击运行或命令行执行时窗口一闪就没了，什么信息都看不到。这不是命令本身坏了，而是 PowerShell 脚本的执行策略默认可能是 Restricted，或者脚本里有错但窗口直接关闭。先跑一下：
Get-ExecutionPolicy如果是 Restricted，改成 RemoteSigned：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser写脚本的时候，文件最好另存为 UTF-8 with BOM，否则中文注释或字符串在 Windows PowerShell 5.1 里会乱码，脚本可能直接失败。想调试脚本不要直接双击.ps1，右键选择“使用 PowerShell 运行”，或者在终端里执行powershell -File xxx.ps1，错误信息至少不会一闪而过。
这个问题很大程度上是因为新手把 Windows 命令和 Linux 命令混着用。记住一个核心区分：WSL 里敲的是 bash 和 Linux 命令，PowerShell 里敲的是 Windows 命令。两个环境共享文件系统，但不共享命令语法，很多“脚本闪退”和“命令找不到”都是这个根源。
4. 把 WSL 变成日常开发环境：四个经典场景实战
4.1 VSCode 配合 Remote-WSL：Windows 界面上写 Linux 代码
我最推荐的日常开发组合是“VSCode + WSL 扩展”。在 VSCode 里装一个微软官方的WSL扩展，标识是ms-vscode-remote.remote-wsl，然后打开任意终端进入你的项目目录，敲：
code .VSCode 会自动检测当前处于 WSL 环境，重新开一个“WSL: Ubuntu”窗口。这个窗口里编辑的文件、运行的终端、执行的命令都在 Linux 环境里，同时你用着 Windows 上的图形界面编辑器。调试器、Git、语言服务器都会直接连到 Linux 侧，不需要在 Windows 再装一套 Python 或 Node 环境。
有个细节值得注意：VSCode 连接 WSL 后，会在 Linux 用户目录下安装一个 VS Code Server。第一次连接需要下载几十 MB 的服务端组件，如果网络慢会有一段时间空白等待。另外，用 Remote-WSL 打开项目时，尽量把项目文件放在/home/用户名/下，不要放在/mnt/c/的 Windows 盘。我在 1.2 节的表格里提过，WSL2 跨文件系统访问性能差，在 Windows 盘上跑npm install或 Webpack 编译会慢到怀疑人生，同样的项目搬到 WSL 家目录下速度直接拉满。
4.2 Windows Terminal：一个窗口管所有环境
Windows Terminal 不是 WSL 的必需品，但绝对是绝配。它支持多标签页和多窗格布局，可以同时开着 PowerShell、Cmd、Ubuntu 三个会话。安装方式直接去 Microsoft Store 搜 Windows Terminal，装完在设置里添加 Ubuntu profile，默认启动目录可以设为\\wsl$\Ubuntu\home\用户名，这样每次打开新标签就直接落到 Linux 工作目录。
Windows Terminal 有几个设置能明显提升体验：拖动标签页可以上下左右分屏，Ctrl+Shift+D复制当前标签，Ctrl+1切第一个 tab。配色方案里可以选 One Half Dark 之类的主题，字体设为 Cascadia Code PL 或 JetBrains Mono，中文显示也没有问题。我把 PowerShell 和 Ubuntu 放在同一个窗口里，左边是 WSL 跑日志，右边是 Windows 侧跑接口测试工具，操作起来像给自己搭了一个小型工作台。
4.3 Docker Desktop 与 WSL2 后端：数据库和中间件一键启动
Docker Desktop 在 Windows 上能跑，核心原因就是把 Docker Engine 放到 WSL2 的 Linux 虚拟机里。安装 Docker Desktop for Windows 后，在设置里勾选“Use WSL 2 based engine”，它会自动创建一个 docker-desktop 发行版。然后在 Resources -> WSL Integration 里勾选想集成的发行版，之后在 WSL 终端里直接敲docker ps就能用，不用额外配 DOCKER_HOST。
为什么要强调 WSL2？因为 Docker 容器依赖 Linux 内核特性，Windows 原生容器兼容性很差，绝大多数镜像都是为 Linux 写的。有了 WSL2，你可以在 WSL 里起一套完整开发栈，例如：
docker run -d --name redis -p 6379:6379 redis:7 docker run -d --name elasticsearch -p 9200:9200 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:8.14.1第一次拉镜像可能比较慢，可以在 Docker Desktop 里配置镜像加速地址。装 Elasticsearch 这类依赖系统参数的服务时，如果报vm.max_map_count不足，在 WSL 终端执行：
sudo sysctl -w vm.max_map_count=262144这只是临时生效。要永久生效的话，在/etc/sysctl.conf里加一行vm.max_map_count=262144。这个参数是 ES、MongoDB、ClickHouse 这类中间件在 WSL 里启动失败的常见原因之一，提前设好能省很多麻烦。
4.4 深度学习环境搭建：WSL2 + CUDA + PyTorch
WSL2 对深度学习非常友好，因为 NVIDIA 官方支持在 WSL2 里使用 Windows 驱动直通 GPU。你只需要在 Windows 侧安装好最新 NVIDIA 显卡驱动，在 WSL 里不需要再装 Linux 版 NVIDIA 驱动。装 CUDA Toolkit 时选择 WSL-Ubuntu 版本，安装方式和其他 Linux 发行版类似。如果只跑 PyTorch，很多人连完整 CUDA Toolkit 都不用装，直接装带 CUDA 支持的 PyTorch 版本即可：
conda install pytorch torchvision torchaudio pytorch-cuda=12.1 -c pytorch -c nvidia用nvidia-smi能确认 GPU 是否在 WSL 里可见。如果你用的是 AMD 7900XTX 这类显卡，则要装 ROCm 版本的 PyTorch，命令大概是：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.0深度学习训练时，建议把数据集放在 Linux 文件系统里，也就是/home/用户名/data/下面，不要放在/mnt/c/Users/...。WSL2 跨盘访问的 IO 瓶颈在大数据量场景非常明显，我以前把数据集放 Windows 盘跑训练，每个 epoch 读取耗时能差三倍以上，把数据挪进 WSL 后，训练速度明显改善。这个原则对所有 IO 密集操作都适用：编译、日志、数据库文件，都放 Linux 侧。
4.5 用 binwalk 分析固件：把 WSL 当成 Linux 工具箱
做 CTF 或者嵌入式开发的朋友应该知道 binwalk。这个固件分析工具在 Windows 上几乎没法用，但在 WSL 里一条 apt 命令就能装好：
sudo apt install binwalk binwalk -e firmware.bin-e参数会自动提取固件里识别出来的文件系统、压缩包和代码段。因为 WSL2 是完整 Linux 内核，binwalk 依赖的 zlib、lzma、uboot 解析工具都能正常工作。就算你不搞 CTF，日常分析路由固件、设备镜像、解包安装包也很有用。WSL 的定位就是这样：Windows 做日常办公和娱乐，Linux 做命令行工具箱，两边文件互通，按场景选择。
用 binwalk 遇到提取失败时，别忘了安装一些辅助工具：
sudo apt install unzip p7zip-full liblzma-dev有些固件里的压缩段需要特定工具才能解开，装齐之后识别率会高很多。WSL 里用 apt 装东西和普通 Ubuntu 完全一样，不用担心搞坏 Windows 系统，这也是我建议大家放心折腾 WSL 的原因之一。
5. 进阶玩法：本地大模型、中间件、发行版迁移与备份
5.1 在 WSL 里部署 DeepSeek 等本地大模型
本地大模型这两年非常火，WSL2 成了很多人的首选实验场。原因很简单：GPU 直通、命令行交互方便、内存管理可以按需调整。部署方式一般是用 Ollama 这类工具，在 WSL 终端里一条命令安装：
curl -fsSL https://ollama.com/install.sh | sh ollama run deepseek-r1:7bOllama 会自动拉取模型并启动本地服务，Windows 侧浏览器访问localhost:11434就能在 Web 界面上聊天。如果内存足够，也可以选 deepseek-r1:14b 甚至更大参数量的模型，但建议先看下显存和内存再决定。WSL 里跑模型时，%UserProfile%\.wslconfig中的 memory 要给足，最好 16GB 以上，否则模型加载到一半，系统可能直接把 WSL 进程杀掉。
一个常见误区是以为 WSL 里的模型下载一定很慢。实际上默认源一般还凑合，但如果你所处网络环境访问这些站点慢，可以考虑配置镜像，或者直接从 Hugging Face 下载模型文件放到 Ollama 缓存目录。这个过程本质上和 Linux 服务器部署大模型一模一样，你在 WSL 里调试好的脚本、端口、模型，后面迁到云服务器上基本零成本，这是 WSL 做开发验证的天然优势。
5.2 Redis、Elasticsearch 别再用 Windows 原生版：WSL 才是正经方案
经常有人搜“redis windows 下载”。其实 Redis 官方并不支持 Windows 原生版本，Windows 上那些第三方移植版版本旧、功能残缺，出问题还没有官方维护。最好的替代方案就是 WSL。在 WSL 里执行：
sudo apt install redis-server sudo service redis-server start redis-cli ping返回 PONG 就能用了。Elasticsearch 虽然官方有 Windows zip 包，但启动起来依赖 JVM 和系统参数，问题很多。在 WSL 里用 Docker 或者直接解压 tar 包跑，都更接近生产环境。WSL 和 Windows 共享网络端口，Windows 上的客户端连接localhost:6379或localhost:9200就能访问到 WSL 里跑的服务，开发体验很顺滑。
有一点容易被忽略：WSL 里的服务不会像系统服务那样自动启动，每次新开终端要手动sudo service redis-server start。如果不想每次手动敲，可以在.bashrc里加一行启动命令，或者把服务启动写成脚本。我第一次用 WSL 跑 Redis，第二天打开电脑发现连不上，排查半天才想起来是 WSL 实例重启了，服务没有自启。后来我写了一个start-env.sh，进入 WSL 敲一下就能把所有依赖服务拉起来，省心很多。
5.3 把 WSL 发行版导出和导入：备份、迁移、离线安装一步到位
说到离线安装和 C 盘空间，我最推荐的手段是wsl --export和wsl --import。这个功能能把整个发行版打包成一个 tar 文件，然后在任意机器、任意路径恢复。步骤很简单，先关掉 WSL：
wsl --shutdown wsl --export Ubuntu D:\backup\ubuntu-backup.tar恢复时，先创建一个目标文件夹，比如D:\WSL\Ubuntu，然后执行：
wsl --import Ubuntu D:\WSL\Ubuntu D:\backup\ubuntu-backup.tar --version 2这样发行版就跑到 D 盘了，C 盘立刻腾出好几个 GB。注意--import导入的发行版默认使用 root 用户登录，需要重新设置默认用户。方法是以 root 进入发行版，编辑/etc/wsl.conf，加一段：
[user] default=你的用户名或者用wsl -d Ubuntu -u root进入后执行对应的用户配置修改。这个功能我强烈建议每个 WSL 用户掌握，因为它既可以做系统迁移，也可以当备份手段，更可以配合离线包实现完全离线安装——拿到 rootfs 压缩包直接 import 就能用，绕开在线下载流程。
迁移到新机器的时候，只要 Windows 上有 WSL2 内核，wsl --import就能把整个环境还原，包括你装过的 Python 包、CUDA 工具链、数据库数据。这个特性比传统虚拟机镜像更轻，也是我敢大胆折腾 WSL 环境的底气。
最后再单独说一个我踩过几次坑之后总结出来的习惯：WSL 里的文件尽量放在 Linux 文件系统，也就是/home/用户名/下面；Windows 和 WSL 之间的数据交换走\\wsl$或共享目录，但项目编译产物、数据库数据、模型权重这些永远放 Linux 侧。WSL 看起来只是一个终端窗口，背地里却是一个完整 Linux 内核，尊重它的运行规律，它就能变成一台近乎免维护的 Linux 开发机。尤其当你把日常脚本、Docker 服务、深度学习环境都搬进去以后，再回头对比以前在 Windows 下硬装 Linux 工具的日子，你会觉得这一步迁移做得太值了。
