Windows 上装了 WSL 之后很多人都会产生同一个疑问一台机器上到底能不能同时跑好几个不同的 Linux 环境我最早用 WSL 时也以为它只能装一个 Ubuntu直到后来做项目需要同时用 Ubuntu、Debian 和 Kali 才去认真研究多发行版的玩法。结论其实很直接WSL 完全支持多个 Linux 环境并存而且生成方式不止一种——既可以用官方命令并排安装也可以通过导出导入复制出同款环境甚至能把 Docker 镜像直接注册成新的 WSL 发行版每个环境都是独立的一套文件系统互不干扰。这篇实战记录会把我在 WSL 里折腾多环境的思路、命令和踩坑经历完整走一遍适合所有已经在用 WSL、或者正准备把 Windows 当成主力开发机的人参考。1. 为什么需要多个WSL环境需求分层与场景分析1.1 三种典型的多环境需求先别急着敲命令想清楚自己为什么需要多个环境才能选对生成方式。以我接触过的场景来看需求基本分三类第一类是试错型。看到新发行版想去试试比如从 Ubuntu 迁移到 Debian 13又或者想体验 Kali 的安全工具。这类需求往往不会长期保留多个环境装完玩几天就可以删掉所以优先考虑官方商店安装方便清理。第二类是隔离型。工作项目 A 需要 Python 3.10 和旧版 Node项目 B 要最新工具链二者依赖互相打架又或者你偶尔要做一些危险实验比如乱改系统配置、装不稳定的内核模块把这些操作放进单独的 WSL 环境里玩坏了直接重置主力环境完全不受影响。这类需求是多数人真正想要的核心手段就是复制或导入环境。第三类是工具型。某些 Linux 发行版有天然的领域优势Kali 自带一整套安全的静态工具Alpine 以极小的体积适合做轻量实验openSUSE 在企业场景更常见。把专用发行版当作一个工具台使用需要时切入用完就停比维护一个塞满各种工具的大杂烩环境更清爽。我自己的主力组合就是一个日常开发环境一个 Kali 工具环境一个专门跑 AI 实验的 CUDA 环境。后面第六章会给你看看具体的搭建过程。1.2 为什么不用虚拟机或双系统一定有人想问多装几个虚拟机不也能实现隔离吗如果能接受虚拟机的代价确实可以。但 WSL 多环境方案的优势在于轻量和文件互访。虚拟机每个实例都要独占固定内存和大量磁盘启动以分钟计算而 WSL2 的每个发行版实际跑在一个由 Windows 虚拟化层托管的轻量级虚拟机实例里启动只要一两秒内存按需分配所有实例共享 .wslconfig 中设置的总资源上限。你可以这样理解如果虚拟机是一间间独立装修的实体房那么 WSL 多环境就是同一栋楼里的独立房间水电资源共用一根总管但每个房间的家具和装修互不影响。和 Docker 容器比WSL 每个发行版又是完整的 Linux 用户空间保留了 systemd、网络栈等完整机制更接近一台真实机器和双系统比则省掉了来回重启的折腾。1.3 动手前先检查环境和版本多环境功能依赖较新的 WSL 版本建议先做一次基础检查。Windows 10 2004 及以上、Windows 11 都可以确认两项 Windows 功能已开启适用于 Linux 的 Windows 子系统和虚拟机平台。打开 PowerShell 执行wsl --status和wsl --version能看到当前默认版本和 WSL 版本号。如果输出提示需要更新执行wsl --update升到最新。本文里的命令都基于新版 WSL1.x 以上老版本用户建议先升级否则部分新命令比如wsl --list --online、wsl --import可能不可用或行为不一致。提示多环境功能从 WSL 1 时代就有了但 WSL 1 的发行版之间共享内核、文件系统行为也和 Linux 原生有差异。除非有兼容性特殊要求否则所有新环境一律用 WSL 2。2. 最省事的并排安装一条命令一个发行版2.1 看看官方仓库支持哪些发行版如果只是想要一个没玩过的发行版官方安装流程已经做得非常傻瓜化。先在 PowerShell 里列出可用发行版wsl --list --online常见输出包括 Ubuntu多个版本、Debian、Kali-Linux、openSUSE、Alpine、Oracle Linux 等每个发行版都有一个短标识比如Ubuntu-22.04、Debian、Kali-Linux。目前官方仓库的发行版不算多但覆盖了主流场景普通需求完全够用。对比一下常见选项发行版标识适合场景备注Ubuntu-22.04 / Ubuntu-24.04通用开发、服务器兼容生态最全资料最多Debian追求稳定、系统极简Debian 13 发布后值得一试Kali-Linux渗透测试、固件逆向自带大量安全工具Alpine极轻量实验、快速验证体积小包管理器是 apkopenSUSE企业环境模拟管理工具丰富2.2 并行安装多个发行版并切换选定后执行安装即可wsl --install -d Debian wsl --install -d Kali-Linux wsl --install -d Alpine每个发行版的首次启动都会让你设置一个专属的 Linux 用户名和密码这和 Windows 账号无关记住这个用户名后面登录和提权都用它。安装完成后用wsl -l -v可以看到所有环境按列表排列每个都带版本号、状态和 WSL 版本。进入某个环境直接指定名字wsl -d Debian wsl -d Kali-Linux不指定发行版时WSL 会进入默认发行版。第一个安装的往往就是默认如果想换用wsl --set-default Ubuntu-22.04这种玩法最符合试错型需求装出来干干净净用腻了直接卸载Windows 商店和 WSL 注册表都会同步清理不留垃圾。2.3 官方安装的局限同名环境只能有一个随手装三五个发行版没问题但如果你想装两个完全相同版本的 Ubuntu 就遇到坎了商店的安装包和wsl --install -d都按发行版名称为唯一标识注册你第二次执行同一发行版的安装命令WSL 要么提示已存在要么会把它当作更新处理不会老老实实生成一个全新实例。这其实是好多人的真实痛点——同一个 Ubuntu既想保持一个干净底座用来做模板测试又想留一个日常主力随便折腾。官方安装不支持这个需求解决办法就是我下一章要写的wsl --export和wsl --import组合拳这可以说是 WSL 多环境玩法的真正核心。3. 复制现有环境export/import 才是多环境的核心武器3.1 一条完整的复制流程wsl --export会把某个发行版的完整文件系统导出成一个 tar 归档wsl --import再把这个归档注册成一个新环境。命令结构如下wsl --shutdown wsl --export Ubuntu-22.04 D:\wsl\backup\ubuntu-22.04.tar wsl --import Ubuntu-Dev D:\wsl\instances\ubuntu-dev D:\wsl\backup\ubuntu-22.04.tar wsl --import Ubuntu-Test D:\wsl\instances\ubuntu-test D:\wsl\backup\ubuntu-22.04.tar第一行先停掉所有正在运行的 WSL 实例避免文件系统写入不一致。第二行把 Ubuntu-22.04 打包。第三、四行分别生成两个新环境名字叫 Ubuntu-Dev 和 Ubuntu-Test安装目录分别是D:\wsl\instances\ubuntu-dev和D:\wsl\instances\ubuntu-test导入数据源都是同一份 tar 文件。注意事项很多但最重要的就是wsl --import的第二个参数安装位置和第三个参数tar 文件是两个完全不同的东西一个是新环境将来存放数据的地方一个是你之前导出的归档原文件。很多人第一次会把两个路径写反结果把 tar 解压到了奇怪的位置。导出的 tar 文件可以反复使用。你可以在一个模板环境里装好常用工具、配好镜像源、写好 .bashrc然后一次性导出以后每次需要新环境就从这个模板派生几分钟就能得到一个定制好的 Linux 工作台比每次从头安装省事得多。3.2 导入后默认 root 用户的处理办法通过 export/import 生成的环境有一个特点默认登录用户是 root。原因很简单——导出文件系统时WSL 的默认用户信息写在了环境元数据里并没有写进 Linux 内部的 rootfs导入时没有元数据可读WSL 只能退回 root。如果你不需要普通用户root 直接干活也问题不大。但想恢复成普通用户登录有两种做法。第一种先以 root 身份进入新环境创建用户并设置密码wsl -d Ubuntu-Dev -u root useradd -m -s /bin/bash dev passwd dev然后编辑/etc/wsl.conf如果没有就新建[user] defaultdev执行wsl --terminate Ubuntu-Dev停掉该环境再次进入就会自动以 dev 登录。注意 wsl.conf 里的用户名必须真实存在于系统中写错的话 WSL 依然会退回 root。还要顺手改一下主机名。复制出来的环境和源环境 hostname 相同在同一个 WSL 网络里容易混淆。修改/etc/hostname和/etc/hosts里的旧名字然后wsl --terminate重启该环境即可生效。3.3 磁盘位置迁移可以一起做掉很多人都会问WSL 文件占了 C 盘怎么办其实最正规的迁移方式就是 export/import。WSL 默认把所有发行版放在系统盘的 AppData 目录下用久了 ext4.vhdx 会越来越大C 盘很快就撑不住。迁移思路很简单导出 tar 放到目标盘再导入时把安装位置指定到目标盘。上面例子里的D:\wsl\instances\ubuntu-dev就是为此准备的。建议目录结构统一一点比如D:\wsl\backup\ -- 存放导出的 tar 归档 D:\wsl\instances\ -- 存放各发行版的 vhdx 和元数据千万别直接从 AppData 里把 vhdx 文件剪切到别的盘再改注册表就算迁移WSL 支持过这种玩法但非常脆弱升级或重装系统后经常出幺蛾子。用 export/import 是官方支持的正路虽然要花几分钟导出导入但稳妥得多。注意wsl --export导出的 tar 里包含虚拟磁盘中的全部数据可能很大。导出前可以先用第五章的方法清理不需要的工具和缓存减小归档体积也减少导入耗时。4. 把 Docker 镜像变成 WSL 环境按需生成任意发行版4.1 原理WSL 发行版本质是一个 rootfs很多人不知道WSL 发行版在底层就是一个完整的根文件系统归档外加少量元数据。官方商店的发行版包本质上也是把一个 rootfs 装进 WSL 注册表。这意味着只要能拿到某个发行版的根文件系统 tar 包理论上都能注册为 WSL 环境。这个观点打开了多环境玩法的天花板你不再受限于官方仓库那几十个发行版任何能在 Docker 仓库里找到的镜像、任何用 debootstrap 构建的最小系统都可以变成 Windows 上一个独立的 Linux 环境。尤其是 Docker Hub 上的发行版镜像本来就是被裁剪好的正式发行版文件系统直接从容器导出成 tar 就能用。4.2 从容器导出 rootfs 并导入假设你想多一个轻量 Alpine 环境但官方商店安装又要走一遍流程更快的方式是从 Docker 镜像生成。先在 WSL 环境里装好 docker engine然后执行# WSL 内执行已装 docker engine docker run -d --name temp alpine sleep 300 docker export temp -o /mnt/d/wsl/alpine.tar docker rm -f temp# PowerShell 内执行 wsl --import Alpine D:\wsl\instances\alpine D:\wsl\alpine.tar关键点是用docker export而不是docker save。docker save导出的是镜像的分层结构包含多层元数据WSL 根本没法直接使用docker export导出的才是容器合并后的完整文件系统是标准 rootfs。这一步写错的人非常多直接导致导入后启动失败或目录结构奇怪。导入后进入系统看一眼wsl -d Alpine cat /etc/os-release你会发现这就是一个干净的 Alpine。如果想要某个特定发行版比如自己定制过的 Ubuntu 容器思路一模一样往容器里装好东西export 出来import 进 WSL。我经常用这个办法做快速验证环境一条命令组一个新系统不需要时wsl --unregister删掉。4.3 用 debootstrap 从零构建最小系统Docker 镜像并不是唯一来源。Debian/Ubuntu 系有个工具叫 debootstrap可以直接从软件源构建一个最小的根文件系统。比如想要一套没有多余组件的 Debian 13可以在现有 Ubuntu WSL 里这么干# 在已有 Ubuntu/Debian 的 WSL 环境里执行 sudo apt install debootstrap sudo debootstrap --variantminbase --archamd64 trixie /mnt/d/wsl/debian-trixie-rootfs https://mirrors.tuna.tsinghua.edu.cn/debian/ cd /mnt/d/wsl/debian-trixie-rootfs sudo tar --numeric-owner -czf /mnt/d/wsl/debian-trixie.tar.gz .Debian 源换成国内镜像后构建速度会快很多。打包时一定要加--numeric-owner否则 tar 会把用户名和组名信息写进归档导入到其他环境时可能出现权限错乱。构建完删除临时目录再回到 PowerShell 导入# PowerShell 内执行 wsl --import Debian-Trixie D:\wsl\instances\debian-trixie D:\wsl\debian-trixie.tar.gzminbase 变体构建出的系统非常精简连 systemd 都没装全。如果后面要跑 docker 或 systemctl先apt install systemd并在/etc/wsl.conf里启用 systemd 支持。4.4 这种玩法的坑自定义 rootfs 导入后有几个细节容易踩坑。第一是没有默认用户登录就是 root需要手动建用户再修改 wsl.conf方法和 3.2 完全一样。第二是网络配置WSL2 导入的发行版通常能自动获得网络但如果你构建的是很精简的系统可能缺少 ifup、ip 等工具ip addr都会提示命令不存在需要按需安装 net-tools 或 iproute2。第三是时区和语言默认 UTC 且没有 locale用起来不太顺手建议在导入后装tzdata、locales把 locale 设为 C.UTF-8 或 zh_CN.UTF-8时区调到亚洲/上海。这套玩法适合追求可复现构建的人。把 debootstrap 命令写成一个脚本以后每次生成环境都执行同一段命令得到的结果几乎一模一样比在图形界面里手动点装要可控得多。5. 多环境日常管理切换、配额、瘦身与卸载5.1 高频管理命令速查环境一多管理命令就得熟练。最常用的几个我列成表方便对照操作命令查看所有环境wsl -l -v进入指定环境wsl -d Ubuntu-Dev以 root 进入wsl -d Ubuntu-Dev -u root停止指定环境wsl --terminate Ubuntu-Dev停止所有环境wsl --shutdown设置默认环境wsl --set-default Ubuntu-Dev导出备份wsl --export Ubuntu-Dev D:\wsl\backup\ubuntu-dev.tar导入环境wsl --import Ubuntu-Dev D:\wsl\instances\ubuntu-dev D:\wsl\backup\ubuntu-dev.tar卸载环境wsl --unregister Ubuntu-Test切换 WSL 版本wsl --set-version Ubuntu-Test 2两个细节提醒。wsl --terminate只停止这一个环境wsl --shutdown会把所有环境全部停掉日常不要随便用全家桶操作。wsl --unregister是删除虚拟磁盘级别的操作环境里所有文件不可恢复谨慎执行我一般会先 export 一份再删即使不需要了也留个救命备份。5.2 用 .wslconfig 限制总资源既然多个环境可能同时运行资源控制就很重要。WSL2 的总内存、CPU 数和交换分区大小由C:\Users\你的用户名\.wslconfig文件统一控制对所有发行版生效。示例[wsl2] memory8GB processors4 swap2GB localhostForwardingtrue [experimental] autoMemoryReclaimgradual networkingModemirrored dnsTunnelingtruememory是 WSL2 虚拟机能用的最大内存不是每个发行版单独 8G而是所有发行版共享 8G 池子。同时开三个环境合计占用不能超过这个值。autoMemoryReclaimgradual是较新版本的功能环境闲置后会把内存逐步归还给 Windows多环境场景强烈建议打开否则开完三个环境后 Windows 主机内存可能被长期占住。networkingModemirrored可以解决 WSL 内服务和 Windows 端口互通的一些老问题也对多环境之间的网络行为更友好。修改 .wslconfig 后记得wsl --shutdown再重新启动配置才会生效。5.3 VHDX 瘦身与安全卸载WSL2 每个环境都对应一个虚拟磁盘文件ext4.vhdx问题是磁盘文件并不会因为你在 Linux 里删文件而自动变小。环境用久了尤其经历过安装大型软件、跑深度学习模型后C 盘占用会虚高不少。这时候需要手动压缩虚拟磁盘。先找到 vhdx 位置。发行版来自 Windows 商店时一般位于C:\Users\你的用户名\AppData\Local\Packages\对应包名\LocalState\ext4.vhdx如果记不清包名用 PowerShell 全盘搜一下Get-ChildItem -Path $env:LOCALAPPDATA\Packages -Recurse -Filter ext4.vhdx | Select-Object FullName停掉所有 WSL 后用 diskpart 压缩diskpart select vdisk fileC:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04LTS_79rhkp1fndgsc\LocalState\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit压缩完确认磁盘占用确实下降。这套流程不用经常做但每个月做完一次能明显缓解 C 盘压力。6. 三个实战环境搭建记录与踩坑复盘6.1 环境规划理论讲完用我自己的环境组合串一遍完整流程。三个环境分工如下环境名发行版生成方式用途DevUbuntu-22.04商店安装后 export 复制日常开发Node、Python、DockerSecurityKali-Linux商店安装binwalk 固件分析、安全工具AI-LabUbuntu-24.04商店安装后 importCUDA、PyTorch 训练实验三个环境全部使用 WSL2。Dev 和 AI-Lab 都基于 Ubuntu 但版本不同环境彻底隔离两边装什么互不污染。6.2 开发环境Ubuntu 加原生 DockerDev 走最常规流程wsl --install -d Ubuntu-22.04首次启动创建用户然后在这个环境里装 Docker。这里我建议用发行版内原生 docker engine而不是 Docker Desktop原因是多环境场景下Docker Desktop 自带的 WSL 后端会和普通发行版抢资源管理上也多一层直接在发行版里跑 docker 更加可控。启用 systemd[boot] systemdtrue然后sudo apt update sudo apt install docker.io docker-compose-v2 sudo systemctl enable --now docker sudo usermod -aG docker $USER如果拉取镜像慢给 Docker 配置 registry mirror比如阿里云容器镜像服务提供的加速地址新建或编辑/etc/docker/daemon.json{ registry-mirrors: [https://加速地址] }重启 docker 服务生效。这套 Dev 环境跑 Web 项目、写脚本、起容器都没问题。由于是商店安装默认用户和 hostname 都是现成的不需要 3.2 那些补救步骤。6.3 安全分析环境Kali 加 binwalkSecurity 环境直接用wsl --install -d Kali-Linux。Kali 官方在 WSL 商店里有正式发行版安装后按照提示创建用户。进去以后和普通 Kali 一样使用 aptsudo apt update sudo apt install binwalk固件分析场景下binwalk 是最常用的工具解析路由器固件、提取文件系统镜像都靠它。WSL 的好处是 Windows 下直接能把固件文件拖到\\wsl$\Kali-Linux\home\xxx\目录再回 WSL 里操作完全不用搞 U 盘或网络共享。需要写脚本批量提取时直接在 Kali 里跑 bash和真实 Kali 体验基本一致。6.4 AI 训练环境WSL2 下的 CUDA 与 PyTorchAI-Lab 是wsl --install -d Ubuntu-24.04再复制出来的实例。WSL2 支持 NVIDIA GPU 透传所以跑 PyTorch 实验完全可行。前提是 Windows 侧装好支持 WSL 的 NVIDIA 驱动WSL 里执行nvidia-smi能看到显卡信息。接着在 WSL 里安装 CUDA Toolkit然后创建虚拟环境安装 PyTorchpython3 -m venv ~/torch source ~/torch/bin/activate pip install torch --index-url https://download.pytorch.org/whl/cu121跑一个小矩阵运算验证 GPU 可用后再装 transformers、datasets 等依赖。这里要注意CUDA Toolkit 和 cuDNN 版本必须和 Windows 驱动支持的 CUDA 版本匹配出现 no kernel image 类报错时多半是 CUDA 版本高于驱动支持范围换低一档的 PyTorch 安装源即可。两个 Ubuntu 环境并存的好处在这里非常明显Dev 里装什么库都不会影响 AI-Lab 里已经调好的 CUDA 环境这对实验复现特别重要。6.5 VS Code 接入与文件互访无论哪个环境VS Code 都是最顺手的编辑器。装上 Remote - WSL 扩展在 WSL 终端里进入任何环境后执行code .VS Code 就会自动以对应发行版为远端打开扩展装在 WSL 侧而不是 Windows 侧。三个环境可以在 VS Code 里开三个窗口互不干扰。文件互访记住两个规则Windows 访问 WSL 文件走\\wsl$\发行版名\路径WSL 访问 Windows 文件走/mnt/c/路径。性能上差很多——WSL 内访问自身 ext4 文件系统是原生速度跨/mnt/c访问 Windows 盘则是网络文件系统级别速度。所以大项目、大依赖一定要放在 WSL 内部不要图方便在 Windows 目录下建工程。6.6 踩坑复盘安装慢、Debian 换源、Docker 更新后起不来第一个坑是wsl --install太慢。表现是下载发行版时卡在正在下载 Ubuntu进度条基本不动。我的处理办法分两步先执行wsl --update --web-download让 WSL 本体走 web 渠道更新再重新执行发行版安装如果还是慢直接打开 Microsoft Store 搜索对应发行版手动安装效果一样。装完系统之后立刻把 apt 源换成国内镜像后续安装软件的速度才有保障不然每次 apt 都要等很久。第二个坑是 Debian 13 换源。Debian 13 默认的源配置不再是老的/etc/apt/sources.list单文件而是换成 deb822 格式文件位于/etc/apt/sources.list.d/debian.sources。改源时直接编辑这个文件把URIs换成清华镜像Types: deb URIs: https://mirrors.tuna.tsinghua.edu.cn/debian Suites: trixie trixie-updates Components: main contrib non-free non-free-firmware Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg安全更新源要单独加一段Types: deb URIs: https://mirrors.tuna.tsinghua.edu.cn/debian-security Suites: trixie-security Components: main contrib non-free non-free-firmware Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg改完sudo apt update速度变化立竿见影。很多人还在老路径sources.list里折腾改完才发现根本没生效就是因为没注意到 Debian 13 的新格式。第三个坑是 Docker Desktop 更新后 WSL 环境起不来。现象是 Docker Desktop 提示更新更新完再打开发现wsl命令卡住或者直接报请启用虚拟机平台。这类问题多半是 Docker Desktop 自动更新了它自带的 WSL 组件和系统里已有 WSL 版本打架。常见解法是关掉 Docker Desktop执行wsl --shutdown然后用管理员权限执行wsl --update最后重启 Windows如果问题反复出现干脆不用 Docker Desktop直接走 6.2 的原生 docker engine 方案省掉这一层依赖。最后说一句个人的使用习惯。我现在日常只常开 Dev 环境Security 和 AI-Lab 都是按需启动用wsl --terminate及时停掉不再使用的发行版配合 .wslconfig 里的内存自动回收主机内存基本不会感觉到压力。多环境带来的最大价值不是我能装多少个 Linux而是每个项目、每个实验都有一个独立、干净、随时可以重建的容器化工作台。希望这套完整的 WSL 多环境玩法能帮你少走弯路把 Windows 开发机真正用出生产力。