企业官网建设流程全解析

WSL2 是我现在唯一在用的 AI 开发环境落点，后面接的大多数模型微调和推理脚本都跑在这套“内核级 Linux + GPU 直通”的组合上。如果你正在纠结 GPU 资源怎么安排、开发环境放哪，这篇是我过去大半年踩坑总结出来的完整部署流程，建议先收藏再动手。

先说我的背景，方便你判断是否适用：我主力机是 Windows 11 + RTX 4090 的台式机，日常要写代码、剪视频、打游戏，不可能为了训练模型就常驻 Ubuntu 双系统；之前试过 VMware/VirtualBox 虚拟机，GPU 性能损失太大，跑 Stable Diffusion 都费劲；云 GPU 按小时计费，调试代码时费用烧得肉疼。后来我把几乎所有 AI 开发环境都搬进了 WSL2——一个基于真正 Linux 内核的轻量虚拟机，配合 GPU 半虚拟化，NVIDIA GPU 在 WSL 里能直接跑 CUDA。实践下来，训练吞吐比原生 Linux 双系统只低两三个百分点，日常几乎无感。

这个环境适合两类人：一是和我一样不想为 AI 开发牺牲 Windows 主力机的朋友；二是团队协作时希望开发环境可复现、能用 Docker 一键拉起 GPU 容器的同学。下面从原理到实操，把整条链路讲透。

1. 为什么我最后选了 WSL2：双系统、虚拟机和云 GPU 的拉锯

1.1 双系统和虚拟机的痛点在哪里

过去我在这个问题上反复横跳过。双系统最大的问题不是性能，而是切换成本：你正写到一半想跑个训练脚本，得先保存 Windows 里的代码，重启，等 Ubuntu 起来，再继续；反过来想回 Windows 处理个文档，又要重启一轮。我试过一周折腾十几次重启，后来干脆不碰 GPU 代码了，直接在云上临时租机调试，白白等队列。

虚拟机则是另一个极端。VMware 和 VirtualBox 都能正常上网、写代码，但 GPU 这块基本是“摆设”：图形加速勉强够用，CUDA 计算性能损耗严重，越新的架构支持越差。而且虚拟机里的 Docker 和内核模块配置起来比物理机麻烦得多，AI 开发里最常用的 GPU 容器、CUDA toolkit、cuDNN 一套下来，光兼容性问题就能耗掉一晚上。

云 GPU 按小时付费看似灵活，但有两个隐含成本：一是数据上传下载很慢，数据集一旦超过几十 GB，来回同步浪费时间；二是调试阶段模型代码改一个参数就要重新跑一轮，每一轮都是钱。真正可行的是把开发调试放本机 WSL2，需要大算力再打包成 Docker 镜像上云，本地和云端共享同一套环境。

1.2 真正的 Linux 内核：WSL2 和 WSL1 的分水岭

很多人听到 WSL 第一反应是“Windows 里模拟出来的 Linux”，这其实是 WSL1 的旧印象。WSL1 用的是系统调用翻译层，把 Linux 的 API 调用翻译成 Windows 的系统调用，兼容性有限，很多需要内核模块的工具根本跑不起来。

WSL2 完全不同。它运行在一个轻量级虚拟机里，加载的是微软基于主线 Linux 内核定制维护的“真内核”——你进去 uname -r，能看到版本号后面带着 microsoft-standard-WSL2 字样。这意味着什么？意味着它能跑 Docker、能加载内核模块、能启动 systemd、能用原生的 CUDA 工具链。你面对的就是一台标准 Linux，只是底下的虚拟化层被微软做得很薄。这就是标题里“内核级 Linux”的含义：不是翻译，不是模拟，是同一个内核。

1.3 我心里那杆秤：性能、成本、折腾时间的权衡

如果把三个方案放在一起对比，我的结论非常清楚：

对我来说，WSL2 是唯一在“不用重启、保持 Windows 主力环境、GPU 性能接近原生”三个条件上都满足的选项。后面所有步骤，都是围绕这套方案展开的。

2. 先搞懂 GPU 直通的原理，不然后面报错你只能瞎猜

2.1 所谓“GPU 直通”其实是 GPU 半虚拟化

我刚接触 WSL2 时也被“GPU 直通”这个词误导过，以为 WSL2 把显卡直接分给了 Linux。实际上 WSL2 的 GPU 支持叫 GPU-PV（半虚拟化），走的是微软虚拟化平台的标准路径。架构上分三层：Windows 侧装 NVIDIA 官方驱动，负责真实管理 GPU 硬件和 CUDA 运行时；WSL2 内核里微软维护了一个 dxgkrnl 虚拟 GPU 驱动，提供 /dev/dxg 设备节点；WSL2 内的用户态 CUDA 库（libcuda、libcudart）把请求通过这个节点转发给 Windows 驱动。

所以一个很反直觉的事实是：WSL2 里的 nvidia-smi 显示的驱动版本，和你 Windows 侧装的驱动版本完全一样。它并没有一套独立的 Linux GPU 驱动。这也解释了为什么微软和 NVIDIA 都强调：WSL2 里不要安装 NVIDIA Linux 版驱动，只要装好 CUDA Toolkit 用户态部分就够了。装错了反而会把 /usr/lib/wsl/lib 下的转发库搞乱，导致 nvidia-smi 消失或者 CUDA 初始化失败。

2.2 性能影响到底在哪一层

搞懂架构之后再谈性能，思路就清晰了。CUDA kernel 编译完以后，本身还是在 GPU 上执行的，不存在“翻译成别的指令”的开销。损耗主要来自每次 API 调用要从 WSL2 用户态穿越虚拟机边界到 Windows 驱动，这个路径多了几次上下文切换和数据拷贝。特征很鲜明：大矩阵运算几乎无损，因为单个 kernel 执行时间长，调用开销被摊薄；小而频繁的 kernel 调用（比如大量 .item() 同步、小 tensor 操作）损耗就比较明显。

理解这一点对你调优很有帮助。我会在第 6 章专门讲实测数据和优化手段，现在先记住结论：训练大模型、做大 batch，WSL2 接近原生；跑频繁小任务的推理服务，要适当调整代码结构。

3. Windows 侧准备：安装、提速与把发行版搬到 D 盘

3.1 系统条件与虚拟化检查

动手之前先确认三件事：系统版本、CPU 虚拟化和内存。Windows 10 21H2 以上或 Windows 11 都行；CPU 的 VT-x/AMD-V 必须在 BIOS 里打开，否则后面会报“WSL2 尚未准备就绪”；内存建议 16GB 起步，跑大模型最好 32GB，因为 WSL2 默认最多吃一半物理内存。

打开方式有两种。新系统最简单，管理员 PowerShell 直接跑：

wsl --install -d Ubuntu-22.04

它会自动把 WSL2、虚拟机平台、Ubuntu 发行版一起装好。老系统或者想手动控制，就分两步走：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

重启后再更新 WSL 内核：

wsl --update wsl --status

看到“默认版本：2”就是正常状态。注意wsl --status里如果提示缺少什么组件，一律先补再继续，避免后面部署到一半才发现地基有问题。

3.2 安装 Ubuntu 并解决下载慢的问题

很多人在这一步卡住：wsl --install下载发行版特别慢，或者 store 应用商店转圈。这不一定是网速问题，往往是 WSL 的在线更新服务不稳定。我的应对方案有三个，按优先级排：

• 先跑wsl --install --no-distribution，只装 WSL2 引擎，然后去微软官网手动下载 WSL 内核离线安装包，装完再单独装发行版。
• 发行版从官网下载 .appx / .msixbundle 离线包，用Add-AppxPackage -Path 文件名安装，比 store 稳。
• 装好 Ubuntu 后第一件事就是换 apt 源。编辑/etc/apt/sources.list，把archive.ubuntu.com换成国内开源镜像站（清华 TUNA、阿里云都可以），然后sudo apt update && sudo apt upgrade。

热词里侧面印证过“wsl2下载慢”是普遍现象，别慌，用离线包+镜像源基本能绕过去。另外提醒一下，WSL 内核不会跟着 Windows Update 自动更新大版本，装完建议定期wsl --update。

3.3 把 WSL2 发行版完整搬到 D 盘

默认 WSL2 发行版放在 C 盘，AI 环境装完 CUDA Toolkit、conda、Docker 镜像、模型权重，轻松占用几十 GB。把发行版迁到 D 盘是保护 C 盘空间的必修课。

方法一（旧版通用，export/import）：

wsl --shutdown wsl --export Ubuntu D:\wsl-backup\ubuntu.tar wsl --unregister Ubuntu wsl --import Ubuntu D:\WSL\Ubuntu D:\wsl-backup\ubuntu.tar --version 2

注意unregister会删掉原发行版所有数据，所以先 export。迁移后最容易被忽略的是默认用户变成了 root，需要重新指定：

ubuntu config --default-user 你的用户名

或者进 WSL2 后编辑/etc/wsl.conf：

[user] default=你的用户名

方法二（新版 WSL 2.0+，直接指定位置）：

wsl --install -d Ubuntu-22.04 --location D:\WSL\Ubuntu

如果你的 WSL 版本支持，这个方法最省事。迁移完成后，建议顺手把虚拟磁盘位置也改到 D 盘，在%UserProfile%\.wslconfig里加swapFile=D:\\wsl-swap.vhdx，给 C 盘减负。

3.4 基础环境初始化：源、编译链与 Python

进入 Ubuntu 后先把基础工具装齐。这一步不需要急着装 CUDA，先把系统弄干净：build-essential 包含了 gcc、g++、make，后面编译 torch 扩展、CUDA 示例都离不开；git、curl、wget 是刚需；openssh-server 按需装。

Python 不要用 apt 直接装系统 python3，版本老且容易污染系统环境。我推荐直接上 Miniconda，后面第 5 章会详细说。现在先装好 conda 的依赖即可：

sudo apt install build-essential git curl wget ca-certificates git config --global user.name "你的名字" git config --global user.email "你的邮箱"

WSL2 里生成 SSH key 时有个坑：默认路径在/home/用户名/.ssh，和你 Windows 的.ssh是两套。如果只想用一对密钥，可以在 Windows 侧配置%UserProfile%\.ssh\config指向 WSL 目录，或者干脆在 WSL 里重新生成并上传公钥。我习惯在 WSL2 里独立一套，Windows 上需要 Git 操作时单独处理，互不干扰。

4. GPU 直通落地：驱动、CUDA 与三次验证

4.1 Windows 显卡驱动是 GPU 直通的总开关

WSL2 的 GPU 直通，Windows 侧显卡驱动是绝对的总开关。NVIDIA 从 470 系列开始支持 WSL2，现在你的显卡驱动只要不是古董版本，基本都自带 WSL 支持。去官网下 Game Ready 或 Studio 驱动都行，装好后在 Windows 的 PowerShell 里跑nvidia-smi，能看到显卡和驱动版本就对了。

注意：驱动版本号建议保持较新，因为 CUDA 12.x 系列要求驱动达到一定版本。RTX 40 系列的用户尤其不要装远古驱动，否则后面 PyTorch 会报 CUDA driver version is insufficient。

我在这一步踩过最大的坑就是：想当然地在 WSL2 里装了 NVIDIA 的 Linux 驱动包，结果覆盖了 /usr/lib/wsl/lib 里的转发版 libcuda，导致 WSL 里nvidia-smi直接消失，PyTorch 也认不到显卡。最后只能wsl --unregister重来。再次强调：WSL2 内不要装 NVIDIA Linux 驱动，它的 GPU 能力完全由 Windows 驱动供给。

4.2 在 WSL2 里安装 CUDA Toolkit

如果只是跑 PyTorch/TensorFlow，其实不装完整 CUDA Toolkit 也可以——官方 pip 包自带了 CUDA runtime。但只要你想写 CUDA C/C++、自定义算子、或者用 nvcc 编译扩展，就一定要装 Toolkit。

NVIDIA 提供了 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-12-4

装完检查nvcc -V，看到 CUDA 版本号就说明 Toolkit 就位了。这里选 12-4 还是 12-1 取决于你用的框架版本，后面章节表格会讲版本矩阵。NVIDIA 的 repo 有多个小版本目录，比如 cuda-toolkit-12-4、cuda-toolkit-11-8，按需精确安装，避免装一堆用不上的组件。

另外，cuDNN 也是 AI 开发的常客。用 apt 装 cuDNN 需要先配 NVIDIA 的 cuDNN repo，我建议在 conda 环境里直接conda install cudnn，省去手动配仓库的麻烦，版本也更好管理。

4.3 三种方式验证 GPU 已经生效

装完别急着开跑，先用最简单的命令验证链路，我把排错顺序固定成三步：

第一步，在 WSL2 里跑nvidia-smi。能看到显卡型号，且驱动版本和 Windows 一致，说明转发链路 OK。如果提示command not found，检查是否装了 nvidia-utils 相关包，或者确认 Windows 侧驱动版本够新。

nvidia-smi ls -l /dev/dxg

第二步，编译一个最小的 CUDA 程序。新建hello.cu：

#include <cstdio> int main() { int deviceCount = 0; cudaGetDeviceCount(&deviceCount); printf("CUDA devices: %d\n", deviceCount); return 0; }

然后nvcc hello.cu -o hello && ./hello，输出CUDA devices: 1就说明 nvcc 和运行时都工作正常。

第三步，用 PyTorch 验证框架层：

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

输出True和显卡型号，整个 GPU 直通链路才算真正打通。三步都过了，再往上搭模型训练环境，基本不会遇到玄学问题。

4.4 CUDA、PyTorch、驱动三者的版本匹配

这是新手翻车率最高的地方，我亲眼见过太多“import torch 后 cuda.is_available() 返回 False”的人。原因多半是版本矩阵没对齐。

安装 PyTorch 时，推荐直接用官方 pip 源指定 CUDA 版本：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

注意一个关键机制：PyTorch 的轮子里自带 CUDA runtime（libcudart、cublas 等），它运行时用的是系统里的 libcuda.so（由 WSL 转发库提供），所以驱动版本只要不低于它编译所需的底线即可。换句话说，你的nvcc -V显示什么版本不重要，重要的是 PyTorch 自带的 CUDA 版本和驱动兼容。我见过有人 nvcc 是老版本但 PyTorch 跑得好好的，也见过反过来，原因就在这里。

5. 搭一套能复现的 AI 开发环境：Conda、VSCode、Docker 三件套

5.1 Miniconda 管住 Python 环境

AI 项目最怕 Python 环境混乱，不同项目要不同版本的 torch、cuda、cudnn，全塞系统 Python 迟早出事。我的方案是 Miniconda，体积小、够用。

curl -fsSL https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -o miniconda.sh bash miniconda.sh conda create -n ai python=3.10 conda activate ai

进去之后，再按第 4.4 的版本矩阵装 PyTorch。如果觉得默认源慢，给 conda 配置国内的镜像源，速度和稳定性都会好很多。这里强调一下：conda、pip 的源配置只影响软件包下载，不影响 GPU 直通，所以不用为了“加速”去做任何网络层面额外操作，保持系统默认网络配置最稳。

conda env 目录默认也放在 WSL2 的 Linux 文件系统里，天然避开了下面 5.4 讲的 IO 陷阱。建环境之前先确认你已经在/home/用户下，别在 /mnt/c 里执行安装脚本。

5.2 VSCode + Remote WSL：日常开发的正确姿势

有了 conda 环境后，日常写代码我基本不碰命令行编辑器，直接用 VSCode 的 Remote - WSL 扩展。它的体验接近“远程开发”，但其实是本地 WSL 内联：VSCode 窗口还是在 Windows 上，但文件、终端、Python 解释器全在 WSL2 里。

操作很简单：VSCode 装好 Remote - WSL 扩展后，左下角绿色图标点开，选择 “Connect to WSL”，它会列出你系统里所有发行版，挑 Ubuntu 进去后直接code /home/你的用户名/项目目录打开项目。Python 解释器选择 WSL 里 conda 环境的 python，就能正常跳转、补全、调试和打断点。PyCharm/DataSpell 也能识别 WSL 解释器，但我个人觉得 VSCode 在 WSL 场景下最顺滑，插件生态也够用。

一个体验细节：尽量把.vscode、settings.json等项目配置放 WSL 目录内，这样即使在 Windows 打开 WSL 路径下的文件夹，配置也不会丢失。Windows 侧不要用“网络路径”方式打开 WSL 目录（类似\\wsl$\...），体验和性能都会差一截，直接让 VSCode 走 Remote 通道。

5.3 Docker 容器吃 GPU：两种路线与多站点 Nginx

Docker 化是 AI 环境可复现的关键。两条路线我都用过，区别如下：

路线一：Docker Desktop + WSL2 backend。安装 Docker Desktop 后，在设置里选择 WSL2，然后勾选让 Ubuntu 集成 Docker 命令。优点是好用直观，缺点是 Docker Desktop 本体会占用内存和磁盘，而且新版对商业用户有许可证要求，个人使用还好，团队要注意。

路线二：WSL2 内直接安装 docker-ce。占用资源更小、更可控，适合长期跑开发环境。

curl -fsSL https://get.docker.com | sh sudo apt install nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

注意：WSL2 里要用 systemd 管理 Docker，需要先在/etc/wsl.conf里开启 systemd：

[boot] systemd=true

改完执行wsl --shutdown再进 WSL 才生效。然后测试 GPU 容器：

docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

跑出显卡信息就说明容器也能直通 GPU。这条链路对团队复现非常有价值：本地用 Dockerfile 构建镜像，推到镜像仓库后，云上 GPU 机器拉下来直接跑，环境完全一致。

我还会在 WSL2 里用 docker-compose 搭一套多站点 Nginx 开发环境，方便同时调试几个 Web 服务。示例 compose 文件：

services: nginx: image: nginx:1.24 ports: - "80:80" - "443:443" volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro ai-api: build: ./ai-api web: build: ./web

nginx.conf 里按 server_name 区分站点，比如ai.local、api.ai.local。Windows 侧编辑C:\Windows\System32\drivers\etc\hosts，加两行127.0.0.1 ai.local和127.0.0.1 api.ai.local，浏览器就能用自定义域名访问 WSL2 里的服务。这套方案对本地多站点开发非常顺手，后续想上 HTTPS 只需把 443 端口和证书挂进 nginx 容器。

5.4 文件系统陷阱：项目数据和数据集千万别放 /mnt/c

这一小节可能是全文对你帮助最大的一段。WSL2 访问 Windows 文件系统（比如/mnt/c/Users/...）走的是 9P 协议，本质上是网络文件系统，大量小文件读写极慢。模型训练时 dataloader 读图片、pip install 解包、git 拉取大仓库，只要目录在 /mnt/c 下，速度会肉眼可见地慢，有时候甚至比原生 Linux 慢 5-10 倍。

正确做法：所有项目、Python 虚拟环境、数据集、模型权重都放 WSL2 的 Linux 原生文件系统里，比如/home/你的用户名/projects、/data。Windows 这边要用文件，通过\\wsl$\Ubuntu\home\用户名\projects路径访问，这样两边读写的性能方向刚好反过来：Windows 访问 WSL 文件比 WSL 访问 Windows 文件快得多。

我踩过一回狠的：图数据集放在 /mnt/c 下训练，一个 epoch 要 20 分钟，把数据挪到 /data 后直接降到 6 分钟。这个改动一分钱不花，性能立竿见影。如果你发现 WSL2 里训练读取慢，先看数据放哪了，再怀疑硬件。

6. 用数据说话：WSL2 和原生 Linux 的差距究竟有多大

6.1 我跑的两个对比场景

说一千道一万，很多人最关心还是性能。我自己用同一台机器、同一份代码，分别在原生 Ubuntu 双系统和 WSL2 里跑过两组对比：

场景一：ResNet-50 在 ImageNet 100 类子集上训练，RTX 4090，batch size 128，混合精度，固定随机种子。对比每秒处理图片数和单 epoch 耗时。WSL2 平均每 epoch 比原生 Linux 慢约 2%-4%，浮动主要来自数据加载进程调度，GPU 利用率基本打满，差异可以接受。

场景二：Stable Diffusion 文生图，512x512，batch 4，20 步采样。两种环境下单张图生成时间几乎一致，差异在 1%-3% 以内，肉眼完全感觉不到。这是因为单张图的一次采样循环里，大量时间花在 GPU kernel 执行上，调用开销占比更小。

第三个数据想说明：你感知到的“慢”，很多时候不是 GPU 直通慢，而是文件系统放错了位置。优化文件布局后，WSL2 在小操作上的差距也能缩小到几乎无感。

6.2 性能损耗来源与优化思路

理解了第 2 章的架构，优化方向就很明确：减少跨 VM 边界的调用频次，增加单次调用的计算量。

• 训练时把 batch size 调大，既有 GPU 利用率收益，也有摊薄调用的收益。
• dataloader 里尽量少用numpy()、.item()这类强制同步操作，它们会打断 GPU 流水线。
• 如果 dataloader 吃不住，把数据先落成内存映射或预取到内存，再喂 GPU。
• WSL2 里多进程 dataloader（num_workers > 0）会有一些调度开销，但通常不是主要瓶颈，可以先用 num_workers=4 起步，观察 CPU 占用再往上加。
• 模型推理服务不要频繁创建销毁 CUDA 上下文，一次初始化常驻，配合批处理接口，性能会很稳。

总的原则：让 GPU 一直在大规模计算，别让它总在等小调用过桥。照着这个思路调优后，WSL2 在我这儿已经和双系统 Ubuntu 没什么体感差异了。

7. 高频报错与翻车现场：一份可照抄的排查清单

7.1 WSL2 尚未就绪和虚拟化相关报错

这个报错基本可以锁定为虚拟化平台没工作。检查顺序：

1. BIOS 里 VT-x/AMD-V 是否开启，这个设置被改回关闭的情况我遇到过两次。
2. 管理员 PowerShell 执行bcdedit /set hypervisorlaunchtype auto，确保 Hyper-V 虚拟机监控程序启动。
3. 重新启动 Windows，再wsl --status确认默认版本是 2。
4. 如果还不行，用管理员执行：

dism.exe /online /cleanup-image /restorehealth wsl --update

另一个常见线索是wsl -l -v显示某个发行版后面标记为 Version 1，而你的功能只支持 2，那就wsl --set-version Ubuntu 2手动转换。转换很慢是正常的，耐心等。

7.2 Vmmem 内存暴涨和 OOM

Vmmem 是 WSL2 的后台进程，默认会吃掉物理内存的一半，AI 训练时不时就会看到它占十几 GB。这不是 bug，是 WSL2 的内存回收策略比较“厚道”。要限速，用%UserProfile%\.wslconfig：

[wsl2] memory=16GB processors=6 swap=16GB swapFile=D:\\wsl-swap.vhdx

配置文件改完后必须wsl --shutdown再启动，否则不生效。限完内存后如果训练任务超出，会出现内核 OOM，日志里看到 Out of memory 或者进程被杀。这通常是 dataloader 多进程或 Docker 构建镜像是内存大户，把 batch 调小或给 WSL2 多分一点内存。我习惯给 WSL 分配 24GB，本机 64GB 内存，留足 Windows 日常使用。

7.3 局域网访问不了 WSL2 的服务

WSL2 默认网络是 NAT 模式，从 Windows 浏览器访问localhost:8000是通的，因为 WSL2 自动做了回环转发。但同一局域网的其他设备（手机、同事电脑）访问 Windows 的 IP:8000 是打不开的，必须手动做端口转发：

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8000 connectaddress=127.0.0.1 connectport=8000

再去 Windows 防火墙里放行 TCP 8000 入站端口，局域网就能访问到 WSL2 里的服务。要注意 WSL2 的 IP 每次重启会变，但上面用 connectaddress=127.0.0.1 就绕开了 IP 变化问题，因为回环转发到的是 Windows 宿主本身。

如果你用的是 Windows 11 22H2 以上，还可以在 .wslconfig 里开网络镜像模式：

[wsl2] networkingMode=mirrored

开启后 WSL2 和 Windows 共享网络接口，局域网设备直接访问 Windows IP 对应端口就能到 WSL 服务，省掉 portproxy 手动配置，也更接近物理 Linux 的网络体验。

7.4 重置、迁移、升级时的数据保护

最后说说最容易让人崩溃的数据问题。WSL2 里跑崩了想重装，or 把发行版迁来迁去，记住一条铁律：先wsl --export再动unregister。我见过有人直接 unregister，conda 环境、模型、数据集全没了的惨案。备份命令我之前都给过，这里再提醒一次自定义发行版名的版本：

wsl --shutdown wsl --export Ubuntu-22.04 D:\backup\ubuntu-2204.tar

日常 Windows 更新后，WSL 内核偶尔会提示需要wsl --update，这不会丢数据，但 Docker 服务可能要重启。如果你在 WSL 里跑了长任务，建议写完自动保存逻辑，再把 Windows 更新暂停设置到任务完成后。

还有个小坑：迁移/export/import 之后，默认用户变成 root 的事，用ubuntu config --default-user 你的用户名即可修复。Windows 侧启动 WSL 后如果发现 cd 回到 root 家目录，八成是 /etc/wsl.conf 里 user 字段没写对。

最后分享一个我一直在用的习惯：所有重要项目目录，每周定时wsl --export一次到 D 盘，保留最近三份。WSL2 的运维容错率很高，但这份保险让我在折腾新环境时可以毫无心理负担地删了重建。这套环境我已经稳定用了大半年，中间经历过 CUDA 升级、内核更新、磁盘迁移，只要按上面这套链路来，基本不会再有让你想摔键盘的时刻。