WSL2+Ubuntu 22.04+CUDA 12.8 深度学习环境搭建实战指南-代码聚汇网

WSL2+Ubuntu 22.04+CUDA 12.8 深度学习环境搭建实战指南

张颖月·2026-09-06·阅读 22 GEO检测（免费）

WSL2Ubuntu 22.04CUDA 12.8

|难度：普通|阅读约 37 分钟

说实话，在Windows上折腾深度学习环境，最让人头疼的往往不是模型本身，而是环境。你兴冲冲把PyTorch装好，一调用torch.cuda.is_available()，返回一个False，整个人直接麻了。我也经历过这个阶段，试过双系统，试过VMware虚拟机，各有各的别扭。直到后来把主力开发环境切到了WSL2的Ubuntu 22.04上，配合CUDA 12.8 Toolkit和最新的Windows驱动，才终于有了一种“环境不再是瓶颈”的感觉。

这篇东西我会按照自己的实操顺序来写：先说清楚为什么要在WSL里装CUDA，再说安装前需要确认哪些东西，然后给两条完整的安装路线，最后是四层验证方法和一堆踩坑记录。内容会很长，但每一步都能落地，适合刚接触WSL、想在Ubuntu 22.04里跑GPU计算或深度学习的读者。

1. 为什么是WSL2 + Ubuntu 22.04：这套环境解决什么问题

1.1 从双系统到WSL2：深度学习环境的三条路线对比

Windows用户想在Linux环境下做GPU开发，传统选择其实不多。装了双系统，训练和日常办公被硬生生拆成两个世界，经常是刚切到Linux跑上实验，那边微信弹了个文件要处理，又得重启切回Windows，一来一回十分钟就没了。虚拟机的方案倒是能同时跑两边，但GPU性能损耗摆在那里，早年玩VMware直通的配置过程简直能劝退一半人。

WSL2不一样，它不是虚拟机，不是模拟器，本质是一个轻量级虚拟机加一层深度集成。微软把虚拟化层做得很薄，让Linux内核直接跑在Hyper-V的虚拟化平台上，同时又把Windows侧的资源通过9P协议、WSLg等机制映射进去。最核心的是，NVIDIA专门为WSL写了GPU驱动转发方案，Linux用户态程序可以调用Windows侧的GPU驱动。这套东西成熟之后，我开始在WSL2里安装Ubuntu 22.04作为日常开发环境。

从我自己的对比来看，三条路线的体验差异非常明显：

方案	GPU性能	切换成本	适用场景
双系统	原生性能，无损耗	需要重启，切换慢	长时间训练，不需要频繁切换
虚拟机	损耗明显，直通配置复杂	可同屏切换，但配置成本高	旧项目兼容，特殊内核需求
WSL2	接近原生，仅驱动转发	秒级切换，Windows和Linux文件互通	日常开发，快速迭代，混合办公

所以如果你和我一样，需要在Windows上处理文档、聊天、看网页，同时又要用Linux环境跑深度学习训练，WSL2几乎是当前体验最均衡的选择。Ubuntu 22.04则是WSL发行版里用户基数最大、教程最多、各种坑都被踩平了的版本，选它做主力基本不会踩到什么生态空白。

1.2 WSL2里的CUDA不是虚拟显卡，是驱动转发

这个概念必须得先讲清楚，否则很多人会栽在驱动安装上。WSL2里运行nvidia-smi能看到GPU信息，很多人下意识以为WSL里也要像普通Linux那样装一个NVIDIA驱动。这是一个非常普遍的错误认知。

WSL2的GPU加速逻辑是这样的：Windows侧安装的NVIDIA驱动包含完整的用户态驱动和CUDA运行库，WSL2的Linux内核通过NVIDIA提供的驱动模块，把Linux侧的CUDA调用转发给Windows驱动处理。你在WSL里看到的/usr/lib/wsl/lib目录，里面装的就是这套转发库，包括libcuda.so.1、libcuda.so这些关键文件。

用生活化的方式理解：Windows驱动是那个真正干活的“投影仪”，WSL里的libcuda.so是“遥控器”。你在WSL里按“遥控器”上的按钮，信号传给Windows侧的“投影仪”，最终GPU帮你运算。所以WSL里安装CUDA Toolkit时，绝对不能再去装Linux版NVIDIA驱动，只需要装Toolkit本身的计算库、开发工具和编译器就够了。

这也是为什么在WSL2里装CUDA比在物理Linux上装简单得多——你省掉了整个驱动安装环节，不用担心内核版本匹配、X11配置、nouveau冲突这些问题。理解了这一层，后面的安装命令你才会知道每一条在干什么。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 动手前的环境检查：Windows驱动和WSL发行版的确认项

2.1 Windows侧驱动版本核对：先过570这一关

CUDA 12.8 Toolkit对驱动版本是有硬性要求的。虽然WSL2里不装Linux驱动，但Windows侧驱动必须足够新，否则Toolkit装了也白装，运行时直接报错。

CUDA 12.8发布时对应的Windows驱动版本是570系列。我在安装前会先去Windows命令行里跑一次nvidia-smi确认驱动版本，或者打开NVIDIA控制面板看系统信息。如果你驱动版本低于570，建议先去NVIDIA官网把Windows驱动更新到最新，然后重启一次再继续。

powershell复制nvidia-smi

输出里Driver Version那一栏就是Windows侧驱动版本，CUDA Version显示的是当前驱动支持的最高CUDA版本。注意，这里的CUDA Version和后面我们安装的Toolkit版本没有必然关系。打个比方，驱动显示“最高支持CUDA 13.0”，但你装的Toolkit是12.8，这完全没问题；反过来驱动版本过低，Toolkit装的是12.8，运行时就会提示驱动不满足最低要求。

另外一个细节是，笔记本用户最好确认自己的NVIDIA驱动是Windows官方版本，而不是设备OEM厂商的远古定制版。OEM驱动更新往往滞后，有时候性能调度策略也怪怪的。我自己的拯救者笔记本，直接去NVIDIA官网下载安装驱动，比用联想电脑管家推荐的版本省心很多。

2.2 安装WSL2和Ubuntu 22.04：慢与坑的避开方式

如果你的Windows还没装过WSL，最直接的方式是用管理员权限打开PowerShell或命令提示符，执行：

powershell复制wsl --install -d Ubuntu-22.04

这个命令默认会把WSL2和选定的Ubuntu 22.04发行版一起装掉。但很多人反馈执行wsl --install时卡在下载环节，半天没动静。我遇到过几次，也帮朋友排查过，总结下来有两个缓解思路。

第一个思路是先分步执行。先用wsl --update把WSL运行时和内核更新到最新，再用wsl --set-default-version 2把默认版本设置成2，最后再单独安装发行版。这个顺序避免了wsl --install同时处理多个下载任务的拥塞。

powershell复制wsl --update
wsl --set-default-version 2
wsl --install -d Ubuntu-22.04

第二个思路是绕过命令行安装，直接打开Microsoft Store，搜索“Ubuntu 22.04.3 LTS”，从商店页面安装。商店下载有时反而比命令行稳定，安装完成后打开Ubuntu终端，设置用户名密码即可。

powershell复制wsl --status
wsl --version

这两条命令用来确认WSL版本和默认版本是否正确。我见过有人在没确认的情况下稀里糊涂装了WSL1，然后发现GPU不能用，其实问题不在CUDA，而在WSL版本。

2.3 磁盘空间和VHDX体积：装完才发现不够就晚了

WSL2的Ubuntu文件系统存储在虚拟磁盘（VHDX）文件里，默认放在系统盘的%LOCALAPPDATA%\Packages\...\LocalState\目录下。问题是很多人系统盘本来就不宽裕，装完Ubuntu后又要装CUDA Toolkit、cuDNN、PyTorch，还有模型文件，几个大件下来几十GB非常轻松。

我在给新环境装CUDA之前，一定会先确认一下WSL里的磁盘剩余空间：

bash复制df -h /

如果剩余空间少于30GB，我建议先处理磁盘扩容或者迁移，再继续装CUDA。我写过一篇专门的WSL目录迁移方案，核心命令是：

powershell复制wsl --shutdown
wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar
wsl --unregister Ubuntu-22.04
wsl --import Ubuntu-22.04 D:\wsl\Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar

注意，wsl --unregister会清除当前发行版的所有数据，操作前务必确保已经导出备份，并且备份文件是完整的。迁移后用wsl -d Ubuntu-22.04进入系统，确认原来的用户数据和软件包都还在。

如果只是需要扩容VHDX文件，可以用diskpart工具的compact和expand命令，不过日常动态扩容一般够用，这里就不展开讲了。总之，空间问题发生在装CUDA之前解决，成本最低。

3. CUDA 12.8 Toolkit安装的两种路线与取舍

3.1 deb仓库安装：适合长期维护和多版本共存

NVIDIA官方针对Ubuntu提供了deb形式的本地仓库包，这种方式是我个人最推荐的。它把CUDA Toolkit的安装路径、依赖关系、后续升级机制全部纳入apt管理，将来想装别的CUDA版本，或者做版本切换，都比手动管理省力。

先到NVIDIA官网的CUDA Toolkit下载页面，选择Linux、x86_64（或你的实际架构）、Ubuntu、22.04、deb(local)。注意页面上的命令会给出一个下载链接，实际文件名以你看到的为准。我的安装过程如下：

bash复制wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-ubuntu2204.pin
sudo mv cuda-ubuntu2204.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/12.8.0/local_installers/cuda-repo-ubuntu2204-12-8-local_12.8.0-570.70.01-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu2204-12-8-local_12.8.0-570.70.01-1_amd64.deb
sudo cp /var/cuda-repo-ubuntu2204-12-8-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-12-8

第二行那个.pin文件的作用是把CUDA仓库的优先级固定在600，防止apt upgrade时把CUDA组件意外升级到不兼容版本。这是很多人容易忽略的细节，不加这个文件，将来系统一升级可能整个CUDA环境就废了。

sudo apt-get -y install cuda-toolkit-12-8安装的是CUDA 12.8的完整工具链，包括nvcc编译器、CUDA运行库、开发头文件、nsight调试工具、性能分析器等等。安装完成后，默认安装路径是/usr/local/cuda-12.8，同时会有一个/usr/local/cuda软链接指向它。如果你后续还想装CUDA 12.6或11.8，同样方式添加对应仓库安装即可，不同版本会各自独立目录共存，不会互相覆盖。

3.2 runfile安装：适合离线环境和精细控制

deb方式需要网络下载仓库包，如果你所在的内网环境拉取官方地址比较慢，或者你需要完全离线的安装包，runfile方式更合适。runfile是一个自解压安装程序，把整个Toolkit都打包在一个.run文件里，拷到目标机器上直接运行。

bash复制wget https://developer.download.nvidia.com/compute/cuda/12.8.0/local_installers/cuda_12.8.0_570.70.01_linux.run
sudo sh cuda_12.8.0_570.70.01_linux.run

运行后进入交互式安装界面，先输入accept接受许可协议，然后在组件选择界面，最重要的是把Driver那一项取消勾选。前面说过，WSL2里不需要Linux驱动，装了反而可能破坏GPU转发机制。这一项去掉后，保留CUDA Toolkit相关组件，继续安装即可。

runfile安装默认会创建/usr/local/cuda软链接，指向你安装的CUDA版本。我建议安装时也勾选Create symbolic link，省得后面手动软链接。此外runfile方式会安装一些额外的代码示例，这些示例对验证环境是否正常很有用。

两条路线怎么选？我的个人习惯是：新环境我用deb方式，因为它好维护，apt也能自动识别依赖；但如果要去客户现场或者离线机器部署，runfile一个文件搞定，省时省力。如果你还在犹豫，直接选deb方式，然后把下面的环境变量配置做了，这套流程覆盖大多数使用场景。

3.3 环境变量和软链接：最后一步决定成败

安装CUDA Toolkit之后，最重要的一步是配置环境变量。很多人在这一步偷懒，结果重启终端后nvcc找不到，或者程序运行时提示找不到libcudart，反过来怀疑是不是CUDA没装好。其实CUDA装好了，只是环境变量没配上。

我习惯把CUDA相关的环境变量写进/etc/profile.d/cuda.sh，这样所有用户登录时都会自动加载，比往~/.bashrc里写更一劳永逸。内容如下：

bash复制sudo tee /etc/profile.d/cuda.sh <<'EOF'
export PATH=/usr/local/cuda/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
EOF
source /etc/profile.d/cuda.sh

注意我写的是/usr/local/cuda而不是/usr/local/cuda-12.8。因为/usr/local/cuda是一个软链接，它会指向当前的默认CUDA版本。这样将来你切换CUDA版本时，只需要修改软链接，环境变量不用动。

查看软链接指向：

bash复制ls -l /usr/local/cuda

如果指向的是cuda-12.8，那说明当前默认版本是12.8。如果你想切到另一个版本，可以手动改软链接，或者用update-alternatives工具管理：

bash复制sudo rm /usr/local/cuda
sudo ln -s /usr/local/cuda-12.8 /usr/local/cuda
nvcc --version

至于cuDNN，它不在CUDA Toolkit的安装包内，需要单独去NVIDIA官网下载。cuDNN解压后把头文件和库文件复制到CUDA安装目录即可：

bash复制tar -xvf cudnn-linux-x86_64-9.x.x.x_cuda12-archive.tar.xz
sudo cp cudnn-linux-x86_64-9.x.x.x_cuda12-archive/include/* /usr/local/cuda/include/
sudo cp cudnn-linux-x86_64-9.x.x.x_cuda12-archive/lib/* /usr/local/cuda/lib64/

4. 验证这次安装的四个层面：从nvcc到PyTorch

4.1 nvcc与nvidia-smi的版本差：先搞清楚谁是谁

装完环境，第一件事是验证。但验证之前你要区分两个命令表达的信息，不然容易被误导。

nvcc --version显示的是CUDA Toolkit的编译器和工具链版本，也就是你把nvcc当成C++编译器时的版本号。nvidia-smi右侧的CUDA Version是当前NVIDIA驱动支持的最高CUDA运行时版本，它表示驱动兼容性上限，并不等于你已安装Toolkit的版本。

我见过很多人在论坛上贴截图，nvidia-smi显示12.8，nvcc --version显示12.6，然后怀疑自己装坏了。其实这两个本来就是不同层面的东西：驱动支持的是驱动API的最高CUDA版本，Toolkit是开发环境里实际使用的编译器和库版本。只要Toolkit的版本不高于驱动支持的最高版本，运行就是正常的。

验证命令：

bash复制nvcc --version

输出中应该能看到release 12.8，同时Cuda compilation tools一行会显示完整的版本号。

bash复制nvidia-smi

输出中可以看到Windows驱动版本和GPU型号。在WSL2里，nvidia-smi显示的驱动版本其实是Windows侧驱动版本，这是正常现象，别把它当成Linux驱动修复目标。

4.2 编译.cu样例：链路通不通的快速判断

环境变量配置好之后，真正的硬核验证不是看版本号，而是实际编译并运行一个CUDA程序。即使是最简单的加法程序，也能验证CUDA编译器、链接器、运行时库、GPU设备可见性整条链路是否正常。

我在第一次装完环境时，通常会写一个最小的探针程序：

bash复制cat > test.cu <<'EOF'
#include <cstdio>

int main() {
    int deviceCount = 0;
    cudaError_t err = cudaGetDeviceCount(&deviceCount);
    if (err != cudaSuccess) {
        printf("cudaGetDeviceCount failed: %s\n", cudaGetErrorString(err));
        return 1;
    }
    printf("CUDA devices: %d\n", deviceCount);
    if (deviceCount > 0) {
        cudaDeviceProp prop;
        cudaGetDeviceProperties(&prop, 0);
        printf("Device name: %s\n", prop.name);
        printf("Compute capability: %d.%d\n", prop.major, prop.minor);
    }
    return 0;
}
EOF
nvcc test.cu -o test
./test

如果输出显示CUDA devices: 1和设备名称，说明整体链路是通的。这个探针程序能验证三件关键事：nvcc能找到并编译CUDA代码，链接器能找到CUDA运行库，运行时能通过WSL的转发机制访问GPU。

如果编译时报错找不到头文件，检查PATH里的/usr/local/cuda/bin是否配置，以及/usr/local/cuda软链接是否指向正确。如果运行时提示找不到libcuda.so.1或libcudart.so.12，检查LD_LIBRARY_PATH以及系统的动态链接器缓存：

bash复制sudo ldconfig

4.3 deviceQuery等官方测试工具

CUDA Toolkit安装后自带了很多官方测试工具，其中deviceQuery是最经典的一个。它比我们自己写的探针程序更全面，会列出所有设备属性、计算能力、显存大小、线程配置上限等信息。

在deb或runfile安装方式下，deviceQuery一般位于/usr/local/cuda/extras/demo_suite/目录下：

bash复制cd /usr/local/cuda/extras/demo_suite
sudo ldconfig
./deviceQuery

如果输出末尾是PASS，说明CUDA Toolkit安装完全正常。bandwidthTest也值得跑一下，它测试GPU的内存带宽，能让你对当前环境性能有一个感性认识。跑一次bandwidthTest，如果带宽数据和你Windows侧跑分差异不大，说明WSL2的转发机制没有造成明显性能损失。这也是WSL2对比传统虚拟机最大的优势。

此外，如果你在安装时选择了安装samples，还可以去/usr/local/cuda-12.8/samples目录下编译运行官方示例。samples里的0_Simple/simplePrintf适合验证CUDA的打印功能，0_Simple/vectorAdd适合验证完整的向量计算流程。不过大多数情况下，deviceQuery跑通就已经足够说明问题了。

4.4 在WSL里让PyTorch吃上cu128

安装CUDA Toolkit的最终目的，对很多读者来说是为了跑PyTorch或TensorFlow。按照我正在用的版本，CUDA 12.8对应当前PyTorch 2.7的cu128轮子，直接用官方index-url安装即可：

bash复制pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128

装完后验证：

bash复制python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"

如果输出是2.7.x True NVIDIA GeForce RTX ...，说明PyTorch已经能通过WSL调用CUDA GPU了。如果返回False，按我的经验，九成是LD_LIBRARY_PATH没有包含/usr/lib/wsl/lib，导致PyTorch找不到libcuda.so.1。这个问题的完整排查过程我在下一节会详细讲。

另外提醒一点，在WSL里使用conda环境的话，PyTorch的CUDA依赖大概率来自pip的wheel包，而不是系统CUDA Toolkit。这意味着你甚至可以不安装完整的CUDA Toolkit，直接用PyTorch官方预编译的CUDA依赖也能跑。但作为开发环境，我建议还是把Toolkit装上，因为很多扩展库（比如flash-attn、triton）编译时需要完整的nvcc和CUDA头文件。

5. 排错记录：WSL+CUDA环境中最容易翻车的角落

5.1 nvcc命令找不到：没配PATH的典型症状

症状很经典：你确认CUDA Toolkit已经安装成功了，/usr/local/cuda-12.8目录下也看得到bin/nvcc文件，但一敲nvcc --version，终端提示command not found。

这种问题的原因只有一个：PATH环境变量没有包含/usr/local/cuda/bin。排查顺序也很简单。先确认文件存在，再确认软链接存在，最后确认环境变量。如果你和我一样把环境变量写到了/etc/profile.d/cuda.sh，记得执行source /etc/profile.d/cuda.sh或者重新登录WSL，因为修改/etc/profile.d下的脚本不会自动生效。

另一种常见情况是你通过sudo -s切到root用户操作，把环境变量写进了root的~/.bashrc，然后回到普通用户发现nvcc又找不到了。解决办法是让普通用户也能加载这些变量，把这行加到普通用户的~/.bashrc里：

bash复制source /etc/profile.d/cuda.sh

或者干脆把PATH和LD_LIBRARY_PATH的配置同时写到~/.bashrc、~/.profile以及/etc/profile.d/，覆盖面最广。

5.2 libcuda.so加载失败：conda背锅最多

这条坑我踩得最狠，也为不少人排查过。症状是PyTorch能正常安装，但一跑torch.cuda.is_available()就报错，错误信息大概长这样：

text复制OSError: libcuda.so.1: cannot open shared object file: No such file or directory

前面说过，WSL2里GPU转发的核心库在/usr/lib/wsl/lib目录下，里面有libcuda.so.1。正常情况这个目录会被WSL自动加入动态链接器搜索路径。但当你进入conda环境后，conda会把LD_LIBRARY_PATH重新设置，覆盖掉原来的路径配置，导致进程找不到libcuda.so.1。

排查时先确认库文件是否存在：

bash复制ls -l /usr/lib/wsl/lib/libcuda.so.1

然后查看当前LD_LIBRARY_PATH：

bash复制echo $LD_LIBRARY_PATH

如果确实缺少/usr/lib/wsl/lib，手动加回去：

bash复制export LD_LIBRARY_PATH=/usr/lib/wsl/lib:$LD_LIBRARY_PATH

如果这个临时变量生效后问题解决了，就把这行配置持久化。我习惯在~/.bashrc里加下面这行，确保每次进入conda环境后还能找得到WSL的GPU转发库：

bash复制export LD_LIBRARY_PATH=/usr/lib/wsl/lib:$LD_LIBRARY_PATH

这里有个容易混淆的地方：有的教程会让你把/usr/local/cuda/lib64也加入LD_LIBRARY_PATH，这本身没问题，但它解决的是libcudart、libcudnn这类开发库的查找问题，和libcuda.so.1是两回事。libcuda.so.1是运行时的驱动转发库，只存在于WSL的/usr/lib/wsl/lib。所以两个路径加全了才稳妥：

bash复制export LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/lib/wsl/lib:$LD_LIBRARY_PATH

5.3 手贱装了Linux驱动：WSL GPU转发直接被废掉

这个坑我必须单拎出来警告，因为它破坏性极强。WSL2里按普通Ubuntu的教程，执行了sudo apt install nvidia-driver-535或类似命令，结果就是重启WSL后nvidia-smi报错，GPU设备找不到了。原因前面原理部分已经讲透：WSL的GPU依赖Windows侧驱动加/usr/lib/wsl/lib转发，在WSL里安装Linux原生驱动会破坏这套机制，甚至可能导致内核模块加载失败。

解药通常是卸载掉误装的驱动并恢复WSL环境：

bash复制sudo apt purge nvidia-driver-*
sudo apt autoremove

然后在Windows侧执行：

powershell复制wsl --shutdown
wsl --update

再次进入WSL，运行nvidia-smi验证是否恢复。我见过极端情况需要重置WSL发行版，所以再次强调，WSL里永远不要安装Linux版NVIDIA驱动。工具箱里的CUDA Toolkit只计算库，驱动转发交给Windows侧就好。

5.4 CUDA多版本共存和WSL磁盘迁移

CUDA Toolkit装一次的数量可以不止一个。我当前主力环境里就同时存在12.6和12.8两个版本，某些老模型还得用11.8的适配。deb方式安装不同版本后，/usr/local/下会各自独立存在cuda-12.6、cuda-12.8等目录，互不干扰。切换默认版本只需要改一下/usr/local/cuda软链接：

bash复制sudo rm /usr/local/cuda
sudo ln -s /usr/local/cuda-12.6 /usr/local/cuda
nvcc --version

你也可以用update-alternatives管理多个CUDA版本，配置一次后通过菜单交互式切换，适合版本频繁变动的场景。需要注意，切换版本后，LD_LIBRARY_PATH里的/usr/local/cuda/lib64会自动跟随软链接指向新版本的库，不用改。

最后说说WSL磁盘迁移。前面提到过系统盘容易爆的痛点，具体操作我再给一次完整可行的流程：

powershell复制wsl --shutdown
wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar
wsl --unregister Ubuntu-22.04
wsl --import Ubuntu-22.04 D:\wsl\Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar

wsl --import后默认会以root用户进入，原来的默认用户可能需要重新设置。如果原来用户名是yourname，可以进入系统后编辑/etc/wsl.conf添加：

ini复制[user]
default=yourname

然后wsl --shutdown再重新启动即可恢复原来的用户登录。磁盘迁移这件事，结合CUDA环境来看，最好是先迁移再安装CUDA，因为迁移会把原有的CUDA环境也带走，省得装好后又要重来一遍。

装完这套环境之后的体会是，WSL2加Ubuntu 22.04再加CUDA 12.8，这套组合已经成了我日常工作流里最顺手的底座。数据文件放在Windows侧，代码在WSL里跑，两边文件互通，图形界面又有WSLg兜底，几乎感觉不到自己是在虚拟机里做开发。哪怕只是想在Windows上跑个Python深度学习小项目，这套环境的性价比也远超传统双系统方案。按上面这个流程来，从零到跑通torch.cuda.is_available()基本不会超过一小时，比起早期折腾半天驱动、重启无数次的老路，已经舒服太多了。