永远雪山最近帮同事配笔记本的时候碰到一个挺有意思的需求：Win11 下已经装好了 WSL 里的 Ubuntu 24.04，但同一个发行版不够用，得再起一个独立的实例用来折腾编译环境，还希望把那个叫 Ubuntu-24.04 的默认名字改成更顺口的命名。原以为这只是 wsl --install 敲两下的事，结果发现“装第二个实例”和“重命名”这两个需求，比想象中要绕不少，坑也多。折腾一晚上把原理和步骤都摸透了，今天整理成一篇完整的实战记录，给同样被 WSL 多实例、重命名问题卡住的朋友一个可以直接照抄的方案。
1. 环境准备与基础安装：先把底座打牢
1.1 为什么会在 Win11 上需要多个 WSL 实例
先说场景。WSL 本身是轻量级虚拟机，装一个 Ubuntu 24.04 对大多数人够用，但实际干活时经常要分环境：一个实例保持干净，专门跑公司项目的构建流程；另一个实例随便折腾，装 ROS、ESP-IDF、OpenCV 这类体积大、依赖多的工具链，装坏了也不心疼。还有的时候需要同时验证不同版本的依赖库，或者给同事复制一个完全一样的开发环境。这时候“再装一个 Ubuntu 24.04”就成了刚需。
WSL 的发行版管理机制和 VMware 不一样，它没有图形化界面里“克隆虚拟机”这种按钮，官方也没有提供直接的 rename 命令（早期版本）。所以很多人第一次尝试时，要么在 Microsoft Store 里反复点安装却没反应，要么复制了整个目录却起不来。这些问题背后其实都是同一个关键点：WSL 的发行版实例在 Windows 侧是通过注册表和一个虚拟磁盘文件（ext4.vhdx）来管理的，多实例和重命名的本质，就是处理这两样东西。
1.2 检查 Win11 系统与开启 WSL 功能
在动手装第二个实例之前，先把基础环境确认好。我这里的操作环境是 Win11 专业版，系统版本 22H2 以上，WSL 内核已经更新到 2.x。如果你的机器是新装的 Win11，大概率还没启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”这两个 Windows 功能。
以管理员身份打开 PowerShell，执行：
powershell复制wsl --install
这条命令会自动启用所需功能、安装 WSL 2 内核，并默认安装 Ubuntu。如果系统里已经装过 WSL，只是没装 Ubuntu，可以单独指定发行版：
powershell复制wsl --install -d Ubuntu-24.04
安装完成后重启系统，首次启动 Ubuntu 时会要求设置 UNIX 用户名和密码。这个用户名会写入实例的默认配置，后面导入导出克隆实例时，默认用户信息不会跟着复制，需要额外处理，后面第 2.3 节会细说。
如果想确认当前 WSL 版本和实例状态，用：
powershell复制wsl -l -v
wsl --version
wsl -l -v 的输出里会列出所有已安装的发行版名称、运行状态和 WSL 版本。我当时的输出是：
text复制 NAME STATE VERSION
* Ubuntu-24.04 Running 2
那个 * 表示这是默认发行版，后面多实例时可以用 wsl --set-default 来切换默认实例。
1.3 wsl --install 卡住与内核更新失败的排查
安装过程中最常见的两个坑，一个是 wsl --install 下载特别慢，另一个是执行 wsl --update 时报“无法启动服务，原因可能是已被禁用或与其相关联的设备没有启动”。
下载慢的问题，我实测下来最稳妥的方式是绕开命令行直接下载发行版安装包。在 Microsoft Store 里搜索 Ubuntu 24.04，手动点“获取”按钮走商店下载，或者从商店页面拿到安装包的下载链接后用 Add-AppxPackage 命令手动安装。这种方法比命令行里干等靠谱很多，因为命令行会从微软的远程服务器拉取，受网络波动影响比较大。新版 WSL 也支持手动下载发行版 tar 包，然后用 wsl --install --from-file 导入，这个后面在第 2.2 节里会用到。
“服务无法启动”这个报错，十次里有八次是“虚拟机平台”功能没开全。打开“启用或关闭 Windows 功能”，确认这三个选项都是勾选状态：
- 适用于 Linux 的 Windows 子系统
- 虚拟机平台
- 虚拟机监控程序平台（有的系统版本显示为“Hyper-V”，如果没装 Docker 可以不勾全，但前两个必须有）
如果功能都开了还报错，再用管理员身份打开“服务”管理界面，找到 LxssManager 和 vmcompute（Hyper-V Host Compute Service）两个服务，确认它们的启动类型是“自动”，状态是“正在运行”。手动启动一次：
powershell复制net start LxssManager
net start vmcompute
我遇到过一次机器上装了第三方虚拟机软件，把 Hyper-V 相关服务禁掉了，导致 WSL 无论如何都起不来，最后通过重新启用 Windows 功能才解决。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 装第二个 Ubuntu 24.04 实例：三种方案实测对比
2.1 思路对比：商店重复安装、复制目录、导出导入
很多人直觉上觉得“装两个”就是再去商店点一次安装，但实际操作会发现，由商店安装的相同发行版在注册表里对应的是同一个实例名，第二次安装要么提示已安装，要么直接覆盖配置。WSL 在设计上并不支持“同名双实例”，所以装第二个实例必须换个思路。
我实测下来有三种可行方案：
- 商店安装另一个不同版本的发行版（比如一个 Ubuntu 24.04，一个 Ubuntu 22.04），但这解决不了“两个都是 24.04”的需求。
- 直接复制 ext4.vhdx 虚拟磁盘文件后导入，速度快，但步骤稍绕。
- 用
wsl --export导出第一个实例为 tar 包，再用wsl --import导入成新名字的新实例。这种方案最灵活，既能“复制一个”，也能“重命名”，还能顺便迁移到其他盘符。
我的建议是优先掌握方案三，因为它一套流程同时解决“多实例”和“重命名”两个问题。
2.2 使用导出导入克隆出第二个 Ubuntu 实例
先进入第一个实例，把需要保留的软件、配置都装好。因为导出的是整个文件系统，所以新实例会完整复刻当前状态，比重新安装一遍再配环境要快得多。
确认第一个实例状态正常后，回到 Windows PowerShell，先关闭所有正在运行的 WSL 实例，避免导出时文件被占用：
powershell复制wsl --shutdown
然后导出当前实例：
powershell复制wsl --export Ubuntu-24.04 D:\WSLBackup\ubuntu2404-base.tar
导出时间取决于实例占用的磁盘空间，一般几个 GB 的实例需要几分钟。导出完成后，用 --import 导入成为新实例，导入时必须指定两个参数：新实例的名称，以及新虚拟磁盘文件的存放目录：
powershell复制wsl --import Ubuntu-24.04-dev D:\WSL\Ubuntu2404Dev D:\WSLBackup\ubuntu2404-base.tar --version 2
执行完用 wsl -l -v 查看，会发现列表里多了 Ubuntu-24.04-dev。此时两个实例的底层文件是完全独立的：Ubuntu-24.04 的数据在自己的 ext4.vhdx 里，Ubuntu-24.04-dev 的数据在 D:\WSL\Ubuntu2404Dev 目录下的新 vhdx 里，互不干扰。
这里有一个我踩过的坑：导入完成后直接运行 wsl -d Ubuntu-24.04-dev，系统会用 root 用户登录，而不是原来实例里的普通用户。原因是 --import 导入的是文件系统快照，但 WSL 在导入时不会自动设置默认用户（商店安装版会在注册表里写 DefaultUid，而导入手动导入的实例默认没有这个值）。解决方法在第 2.3 节。
复制 vhdx 文件的方式本质上也类似，前提是必须先 wsl --shutdown，然后到 %LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_*\LocalState\ 目录下找到 ext4.vhdx，复制一份到新目录，再用 wsl --import 新名字 新目录 复制的vhdx --version 2 导入。不过这个方法容易因为目标盘格式、文件占用等问题失败，所以我不太推荐给新手。
2.3 克隆后默认用户与 hostname 的调整
给克隆出来的实例设置正确的默认用户，是让整个流程“看起来专业”的关键一步。WSL 实例的用户默认配置有两个作用域：一个在 Windows 注册表里，由发行版安装程序写入；另一个在 Linux 的 /etc/wsl.conf 里。
手动导入的实例没有对应注册表项，最简单的办法是直接改 /etc/wsl.conf。先以 root 身份进入新实例：
powershell复制wsl -d Ubuntu-24.04-dev -u root
然后查看 /etc/wsl.conf 是否已有用户配置：
bash复制cat /etc/wsl.conf
如果没有或者没有 [user] 段，用 root 用户写入：
bash复制echo -e "[user]\ndefault=你的用户名" | sudo tee /etc/wsl.conf
写完退出实例并让它完全停止：
powershell复制wsl --terminate Ubuntu-24.04-dev
再重新进入：
powershell复制wsl -d Ubuntu-24.04-dev
此时登录的应该就是普通用户了。如果导入的 tar 包里原本就有 /etc/wsl.conf，也要检查 hostname 配置。默认情况下导入实例的 hostname 会变成新实例名（比如 Ubuntu-24.04-dev），但如果你在旧实例里手动改过 hostname，复制后可能会出现两个实例 hostname 相同的情况。检查方式：
bash复制hostname
如果需要区分，编辑 /etc/hostname 和 /etc/hosts，改成不同的名字。这个细节在同时开多个 WSL 终端时非常有用，看一眼命令行提示符就知道自己在哪个环境里。
3. 重命名 WSL 发行版：三种方法哪种更稳
3.1 新版 WSL 自带的 --manage 命令
先给个好消息：较新版本的 WSL（2.4.4 及以上）已经在官方命令行里加入了直接重命名的能力。如果你的 wsl --version 显示版本号在 2.4.4 或更高，直接执行：
powershell复制wsl --manage Ubuntu-24.04-dev --set-name Ubuntu-Ros
这个命令相当于 Windows 侧“改了个标签”，不涉及文件系统迁移，速度很快。它会把发行版名称从 Ubuntu-24.04-dev 改成 Ubuntu-Ros，之后所有 wsl -d、wsl --set-default 操作都用新名字。
不确定自己的 WSL 版本支持不支持，可以用 wsl --help 查看管理命令里有没有 --manage 的相关说明，或者直接执行 wsl --version 看版本号。如果版本低，先运行 wsl --update 升级内核。升级过程中如果遇到服务启动类报错，回到前面 1.3 节排查。
3.2 导出导入法实现重命名（通用且稳）
如果你的 WSL 版本太老，或者系统环境比较复杂，可以直接用导出导入来做“重命名”。这个方法的本质是：导出旧实例文件系统，用新名字导入成新实例，再注销旧实例。
完整步骤如下：
powershell复制wsl --shutdown
wsl --export Ubuntu-24.04-dev D:\WSLBackup\ubuntu2404-renamed.tar
wsl --import Ubuntu-Ros D:\WSL\UbuntuRos D:\WSLBackup\ubuntu2404-renamed.tar --version 2
wsl --unregister Ubuntu-24.04-dev
执行 wsl --unregister 后，旧实例的虚拟磁盘文件会被删除，所有数据不可恢复。所以一定要确认新实例能正常进入后再注销旧实例。我的习惯是在 wsl --unregister 之前，先用 wsl -d Ubuntu-Ros 进入，检查关键目录和文件都在，再回去注销。
这个方案唯一的缺点就是导出和导入耗时较长，而且导入后同样需要处理默认用户问题（参考 2.3 节）。好处是它可以顺便把发行版数据迁移到其他盘，比如 C 盘空间紧张时，导入时把目录指定到 D 盘，一步到位。
3.3 注册表直接改名（应急方案，有风险）
还有一个偏门但可行的方法：直接改 Windows 注册表。WSL 的发行版信息存储在：
text复制HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss
这个键下每个子项对应一个发行版实例，其中 DistributionName 就是显示名。理论上只要用 regedit 修改这个值，就能实现重命名。
但这种做法有几个隐患：
- WSL 服务可能缓存旧的名称，改完必须
wsl --shutdown再重启终端才生效。 - 部分发行版在商店端注册的启动器路径还指向旧名字，可能导致快捷方式、Windows Terminal 配置里的启动命令失效。
- 手动改错注册表值可能让其他发行版也一起出问题。
所以除非你只是临时救急，且手头没有导出空间，一般不建议用注册表方案。
4. 多实例管理与日常使用技巧
4.1 用 wsl -l -v 与默认实例区分多个环境
装了多个实例之后，最烦的是分不清当前在哪个环境里。Windows Terminal 或 PowerShell 中可以用：
powershell复制wsl -l -v
这个命令会列出所有发行版及运行状态。wsl --set-default Ubuntu-Ros 可以把某个实例设为默认，这样直接在终端里输入 wsl 进入的就是它。
我在实际使用中会把“默认实例”设置成日常开发用的实例，比如刚重命名完的 Ubuntu-Ros，而把 Ubuntu-24.04 作为备用环境。这样平时直接敲 wsl 就能进入主力环境，需要环境隔离时再用 wsl -d Ubuntu-24.04 显式切换。这种做法在 VSCode 里尤其重要，因为 VSCode 的 WSL 扩展默认连接的也是默认实例。
另外一个非常实用的小技巧：修改 /etc/wsl.conf 里的 [network] 和 [interop] 配置时，不同实例可以差异化设置。比如何时启用 Windows 路径互操作、主机名生成规则，这些每个实例都是独立的。
4.2 磁盘占用清理与 vhdx 文件瘦身
WSL 的虚拟磁盘文件会随着使用越来越大，而且删除 Linux 内部文件后，vhdx 文件不会自动收缩。多实例环境下，这个问题更明显。如果你发现 C 盘空间吃紧，先看一下每个实例的虚拟磁盘位置：
- 商店安装的实例一般位于
%LOCALAPPDATA%\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_*\LocalState\ext4.vhdx - 手动导入的实例位于你自己指定的目录，比如之前例子里的
D:\WSL\UbuntuRos
瘦身的方法是在实例内执行 fstrim 后，再到 PowerShell 里压缩 vhdx：
bash复制sudo fstrim -a
powershell复制wsl --shutdown
diskpart
打开 diskpart 后依次执行：
text复制select vdisk file="C:\Users\你的用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_...\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
我实测过，一个内部删除过大量构建产物的实例，用这种方式从 60GB 瘦身到 20GB 左右，效果很明显。多个实例建议逐个操作，别同时 attach。
4.3 在 VSCode 和 Windows Terminal 里配置多实例
日常开发中，我基本上都在 VSCode 里写代码，通过 Remote-WSL 连接 WSL 实例。如果连接的是默认实例，VSCode 会自动感知；如果要用非默认实例，需要在 VSCode 左下角打开远程窗口时选择“连接到 WSL”，并在弹出的列表里指定具体发行版。
Windows Terminal 里也可以为每个实例创建独立“配置文件”。在 Windows Terminal 的设置里找到“配置文件”->“新建”，命令行填：
powershell复制wsl -d Ubuntu-Ros
再把启动目录指定到 WSL 里的工作目录：
powershell复制wsl -d Ubuntu-Ros --cd ~
这样 Windows Terminal 的下拉菜单里就会出现两个独立的 Ubuntu 入口，一个叫 Ubuntu-24.04，一个叫 Ubuntu-Ros，互不干扰，打开就能用。比每次手动敲 wsl -d 要顺手得多。
5. 常见问题排查与操作速查表
5.1 问题速查表
| 现象 | 原因 | 处理方法 |
|---|---|---|
wsl --install 下载慢 |
远程服务器连接不稳定 | 改为 Microsoft Store 安装；或下载 tar 后用 --import 导入 |
wsl --update 报服务无法启动 |
Windows 功能未完全开启或服务被禁用 | 启用“虚拟机平台”，启动 LxssManager、vmcompute 服务 |
| 导入的实例登录后是 root | 手动导入未设置默认用户 | 配置 /etc/wsl.conf 的 [user] 段，再 wsl --terminate |
| 重命名后发现 VSCode 连接失败 | 扩展未刷新，或连接的是默认实例 | 重启 VSCode，确认当前默认实例，或手动指定发行版名 |
| 复制 vhdx 导入后无法启动 | 复制时实例仍在运行或文件损坏 | 先 wsl --shutdown，再复制，导入新目录 |
| 多个实例 hostname 相同 | 导出复制把配置也带过来了 | 修改 /etc/hostname 和 /etc/hosts 后重启实例 |
| C 盘空间被 WSL 占满 | vhdx 不自动收缩 | 实例内 fstrim，再用 diskpart 压缩 vhdx |
这张表是我在这次折腾过程中实际遇到过的全部问题，前四个出现的频率最高，尤其是“导入后 root 登录”这个坑，几乎每个用过 --import 的人都会踩一遍。
5.2 几个必须养成的操作习惯
使用 WSL 多实例时，有几个习惯能帮你少走很多弯路。
第一个习惯是“动系统前先导出”。WSL 的虚拟磁盘就是一个大文件，操作实例之前用 wsl --export 导出一份 tar 包，相当于给整个 Linux 环境拍了快照。即使后面把系统折腾坏了，也可以随时导入恢复。我一般在给某个实例装大型工具链前，都会花几分钟导出一份备份。
第二个习惯是“区分实例用名字，别用默认值”。装完第二个实例后，第一时间给它设置一个有意义的名字，再改掉 hostname。实测下来，名字里有业务含义（比如 Ubuntu-Ros、Ubuntu-ESP32 这样）会极大减少误操作时进错环境的概率。
第三个习惯是“重命名前检查注册表和终端配置”。如果你之前给实例设置过 Windows Terminal 启动参数、VSCode 远程连接配置或者任务计划，改完名字后这些配置里可能还写着旧名字。所以重命名之后，我习惯先用 wsl -l -v 确认列表，再逐个把终端配置、脚本里的旧名字替换掉。
5.3 一次完整的后续扩展场景
这套多实例的管理方式不止能装 Ubuntu 24.04，WSL 2 下同样可以用 wsl --import 导入其他发行版镜像，比如 Debian、Alpine，甚至从网络上下载的云镜像 tar 包。只要 tar 包内是根文件系统结构，就能注册成一个新实例。
我个人的体会是，WSL 的“实例”概念其实比虚拟机更轻盈：每个实例就是一个 vhdx 文件加一个注册表项，弄清楚了这两层关系，绝大多数安装、克隆、重命名的问题都能自己推出来。如果后面你还想进一步扩展，比如给不同实例分配不同的资源限制、把某个实例单独打包发给同事，核心思路依然是 export 和 import 这两板斧，变化不大。
最后再分享一个小技巧：如果你经常在两个实例之间复制文件，直接通过 WSL 内部的挂载路径访问 Windows 盘符效率很高，但反过来在 Windows 侧访问 WSL 内部文件就没那么方便。我的做法是在 Windows 侧建一个共享目录，两个 WSL 实例都在 /mnt/c/share 下读写，这样既避免了跨实例拷贝，也不会误操作虚拟磁盘文件。这个办法简单但非常好用，尤其是在两个实例分别负责不同编译任务时，共享中间产物简直是刚需。