做 AI 开发这几年，我对环境折腾这件事一直有种矛盾感。Windows 下装 PyTorch 倒是方便，但一到编译 C++ 扩展、跑 shell 脚本、做模型推理部署，尤其在碰到一些只发 Linux 二进制包的库时，Windows 那套环境就处处掣肘。双系统又太伤，来回重启浪费时间不说，Windows 端的数据和 Linux 端的项目还不能随时互访。直到我认真把 WSL2 用起来之后，这个问题才算彻底解决。它本质上是一个运行在 Windows 内部的轻量虚拟机，带完整 Linux 内核，支持 GPU 直通，让 Windows 用户也能丝滑地跑 CUDA、PyTorch、大模型推理这类标准的 AI 工作流。
这篇文章我会把 WSL2 从环境选型、安装配置、GPU 直通验证、CUDA 环境搭建到常见报错排查，完整走一遍。适合刚入手深度学习、想做本地大模型推理、或者受不了 Windows 原生 Python 环境的开发者。你要是已经装了 WSL2 但 GPU 一直不工作，可以直接跳到第三节和第五节看排查思路。
1. 为什么选择 WSL2 搭建 AI 开发环境
1.1 WSL2 不是“虚拟机”那么简单
很多朋友一听“虚拟机”就下意识拒绝，觉得性能有损耗、操作也麻烦。但实际上 WSL2 跟传统虚拟机差别非常大。WSL1 还是个 API 翻译层，把 Linux 系统调用转成 Windows 调用，跑起来快但兼容性有限，很多依赖系统调用的程序根本跑不了；WSL2 干脆换了个思路，直接在一个轻量化的 Hyper-V 虚拟机里跑一个完整的、经过微软优化裁剪的 Linux 内核。
这意味着什么？你在 WSL2 里拿到的不是一个模拟出来的 Linux 外壳，而是货真价实的 Linux 内核，系统调用几乎 100% 兼容。什么 systemd、Docker、CUDA 驱动栈、eBPF，甚至一些内核模块，都能正常工作。我在 WSL2 里跑过 Docker 容器、编译过 Linux 内核模块、跑过需要 io_uring 的异步程序，体验和物理机上的 Ubuntu 几乎没有差别。
另一个容易忽略的点是启动速度。WSL2 的虚拟机不是传统 VM 那种冷启动流程，而是按需启动、后台常驻，第一次进入需要几秒钟，之后开一个终端窗口几乎就是秒开。加上 VS Code 的 Remote-WSL 扩展，整个开发体验非常接近本机操作，不会有“我在一台虚拟机里”的割裂感。
1.2 GPU 直通的原理与真相
标题里“GPU 直通”其实是个容易让人误会的说法。WSL2 并不是像 VMware 那样把 NVIDIA 显卡完整分配给虚拟机，而是通过微软和 NVIDIA 合作开发的 GPU-PV（GPU 半虚拟化）技术，在 WSL2 内核里暴露了一个/dev/dxg设备节点，把 CUDA 调用转发给 Windows 宿主侧的显卡驱动。
真正干活的时候，你从 Linux 侧发的 CUDA 请求，会经过 WSL2 的 dxgkrnl 驱动，由 Windows 的 NVIDIA 驱动执行，最后把结果返回给 Linux 侧。这个转发层的开销在大多数深度学习任务里完全可以忽略不计。我在 WSL2 里跑 Stable Diffusion 的 fp16 推理和一个 7B 规模的模型微调，显存占用、速度与双系统裸跑几乎没有可感知的差别。
这里有一个关键结论，很多人被各种教程绕晕了：WSL2 里不需要安装 Linux 版的 NVIDIA 驱动。你只需要在 Windows 侧装一个支持 WSL2 的 NVIDIA 驱动，WSL2 内部就能直接通过 nvidia-smi 看到显卡。Windows 驱动就是 Linux 侧的驱动，没有双份驱动的概念，这比双系统省心太多了。
1.3 双系统、纯 Windows、远程服务器，怎么选
我身边不止一个朋友在环境选型上纠结很久，我说说自己的对比结论。
双系统的优势是性能最完整、兼容性最好，但代价是切换成本极高。开发过程中经常要查文档、看教程、发消息，这些都在 Windows 侧，来回重启一次至少五分钟，除非你一个上午只专注在一件事上，否则效率损失非常大。
纯 Windows 跑 AI 的问题在于生态。TensorFlow 和 PyTorch 在 Windows 上的支持已经好了很多，但一旦你要用一些底层依赖 Linux 的库，比如某些只提供.so的推理引擎、需要编译驱动的项目、或者要部署到 Linux 服务器的代码，Windows 就很容易卡壳。而且 Docker Desktop 在 Windows 上默认要跑一个 Linux VM，最终还是绕回 Linux 环境。
远程服务器适合模型训练和部署，但日常开发和调试不适合。就算内网延迟低，SSH 来回传文件、编辑器远程插件的体验，终究不如本地顺手。而且私有数据放远端，很多人心里不踏实。
WSL2 正好卡在几者中间：本地实时交互、Linux 内核兼容、能跑 Windows 下的 IDE 和浏览器。我现在的工作流是：WSL2 里管理代码、跑训练和推理，Windows 侧开浏览器看文档、用微信沟通、用截图工具做记录，两边通过 VS Code Remote 无缝衔接，体验相当顺畅。
2. 环境准备与安装配置
2.1 硬件和系统版本要求
先说硬性条件，免得你装到一半卡壳。
- Windows 10 版本 2004（20H1）及以上，或者 Windows 11。低版本的系统默认不支持 WSL2，需要手动开启“虚拟机平台”功能，很折腾。
- 主板 BIOS 里必须开启虚拟化技术，Intel 叫 VT-x，AMD 叫 SVM。这一步很多人忽略，导致报“无法启动，因为此计算机上未启用虚拟化”。
- 内存至少 16GB。跑深度学习训练或者加载大模型，16GB 是入门水平，想要舒服一点建议 32GB。
- 显卡方面，NVIDIA 显卡是体验最好的，驱动从 470.76 版本开始支持 WSL2 CUDA；AMD 显卡也能用，但 AI 生态的兼容性和 CUDA 完全不能比。
系统的内存分配也值得注意。WSL2 默认最多使用宿主机 50% 的内存，如果 Windows 侧同时开着浏览器和一堆软件，内存很容易吃紧。后面我会讲怎么通过.wslconfig文件手动控制分配，反正 16GB 内存的用户建议先提前做好心理准备。
2.2 标准安装流程
现在的 Windows 11 安装 WSL2 很简单，管理员权限打开 PowerShell 或 Windows Terminal，一条命令：
wsl --install这条命令会自动开启需要的 Windows 功能，下载内核，设置默认发行版为 Ubuntu，整个过程基本不用干预。如果要做 AI 开发，我建议显式指定 Ubuntu 22.04：
wsl --install -d Ubuntu-22.04安装完成后重启电脑，重启完系统会要求你设置 Linux 用户名和密码，然后你会落到一个 Bash 提示符下。到这里 WSL2 骨架已经搭好了，你可以先跑一下uname -r确认内核版本，能看到内核版本号说明 WSL2 已经正确工作。
我建议跟着做两件事：第一，运行sudo apt update && sudo apt upgrade -y把系统更新到最新；第二，安装基础工具链：
sudo apt install -y build-essential git curl wget unzipbuild-essential 里的 gcc、g++ 和 make 是后面编译很多 Python 包时的硬依赖，不装的话你会碰到各种莫名奇妙的编译报错。
2.3 离线安装与下载慢的解决思路
很多人的 WSL2 安装卡在下载 Ubuntu 镜像这一步，要么是网络差，要么是断点续传出问题。我在帮同事排查时常见的现象是：wsl --install跑半天，最后报个超时错误，再试一次又从零开始。
碰到这种问题，我推荐两种替代方案。
第一种，直接打开 Microsoft Store 搜索 Ubuntu 22.04，从商店页面点击安装。商店下载本身支持断点续传，速度通常比命令行稳定。装完以后，从开始菜单直接启动 Ubuntu，首次启动同样会要你设置用户名密码。
第二种，如果连商店都慢，可以用手动下载方式。打开浏览器访问 Ubuntu WSL 镜像的官方下载页面，下载.appx或者.msixbundle文件，然后双击安装。这种方式的好处是下载过程可以被浏览器接管，支持多线程加速，下载完了以后安装是秒级完成的。下载完把文件后缀改成.zip，解压后运行里面的ubuntu.exe即可完成注册。
还有一点，很多教程会教你设置 apt 国内镜像源，这个我强烈建议做。在/etc/apt/sources.list里把archive.ubuntu.com替换成可用的国内镜像地址，不然装 CUDA 和 PyTorch 依赖时会等到怀疑人生。
2.4 Ubuntu 22.04 还是 24.04
写这篇之前我专门对比过两个版本。当前阶段，我建议选Ubuntu 22.04 LTS。
原因很简单：AI 工具链的兼容性。PyTorch、TensorFlow 这些框架的预编译 wheel 包，对 Ubuntu 22.04 上的 Python 版本（3.10）和 GCC 版本支持是最成熟的。Ubuntu 24.04 默认带的 Python 3.12 和更新的 OpenSSL，反而可能和一些还没跟上节奏的库产生依赖冲突，我在 24.04 上安装某些旧版 CUDA 工具链的时候就踩过坑。
如果你想用 24.04 图个新，也不是不行，但要做好心理准备：要么所有套件都手动编译，要么碰到某些老库安装不上的情况时自己去折腾兼容方案。做 AI 开发最重要的是环境稳定，没必要为了系统版本新而给自己找麻烦。22.04 的维护期到 2032 年，完全够用了。
3. GPU 直通与 CUDA 环境搭建
3.1 宿主机驱动优先原则
前面说过，WSL2 的 GPU 支持依赖 Windows 侧的驱动，所以第一步永远是把 Windows 上的 NVIDIA 驱动升级到最新或足够新的版本。打开 Windows 的nvidia-smi看一下 Driver Version，如果低于 511，建议直接去 NVIDIA 官网下载对应显卡型号的最新驱动。
我在实际部署中验证过的一个结论是：Windows 驱动版本不要太追求新，也不要太旧。太新的驱动偶尔会和某些 CUDA 版本的镜像仓库存在小冲突，太旧则不支持 WSL2 的 CUDA 转发。相对稳妥的选择是 NVIDIA 官网的 Game Ready 或 Studio 驱动，Studio 驱动稳定性更好，适合搞开发和训练，我工作室的机器一直用 Studio 驱动。
驱动装好以后，在 WSL2 终端里直接运行：
nvidia-smi如果能看到类似下面的输出，说明 GPU 直通链路已经通了：
+---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.154.05 Driver Version: 536.67 CUDA Version: 12.2 | +---------------------------------------------------------------------------------------+这里注意一个细节：输出里显示的 CUDA Version 只是驱动支持的 CUDA 最大版本，不代表 WSL2 里就能直接用这个版本的 CUDA。你还需要在 Linux 侧单独安装 CUDA Toolkit。
3.2 在 WSL2 内安装 CUDA Toolkit
WSL2 里安装 CUDA Toolkit，我推荐用 NVIDIA 官方提供的 WSL-Ubuntu 软件源，比直接去官网下载 runfile 安装方便得多，升级维护也简单。针对 Ubuntu 22.04，依次执行：
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-get update sudo apt-get -y install cuda-toolkit-12-4这里有个容易踩的坑：很多人直接执行sudo apt install cuda，这个包会安装所有 CUDA 组件，包括驱动相关的东西，体积巨大且容易冲突。装cuda-toolkit-12-4这种带版本号的包就够了，它只装编译器和开发库，不含驱动。
装完以后配置环境变量。编辑~/.bashrc，末尾追加：
export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH然后执行source ~/.bashrc，再运行：
nvcc --version能正常输出版本号，说明 CUDA Toolkit 已经就位。
3.3 安装 PyTorch 并跑通 GPU 验证
有了 CUDA Toolkit，接下来装深度学习框架就顺理成章了。我现在的工作环境是 Python 3.10 + PyTorch，建议先用 venv 隔离环境，别把系统的 Python 环境搞乱。
python3 -m venv ~/ai-env source ~/ai-env/bin/activate pip install --upgrade pip注意，PyTorch 的安装源分 CPU 和 GPU 版本。直接用pip install torch默认装的是 CPU 版，你得指定 CUDA 版本对应的 wheel 源：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124这里cu124表示 CUDA 12.4，如果你的 toolkit 是 12.4 就选这个。安装完成后写一个最简单的验证脚本：
import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0))如果torch.cuda.is_available()输出True，说明 PyTorch 已经能用上 GPU。我再建议用一个几秒钟就能跑完的真实计算验证一下，而不是只查布尔值：
import torch a = torch.randn(10000, 10000, device="cuda") b = torch.randn(10000, 10000, device="cuda") c = torch.matmul(a, b) print(c.sum().item())能正常输出一个数值，就说明显存分配、计算内核、内存交换全链路都没问题。我第一次配完测这个矩阵乘法的时候，看到那一瞬间的输出，心里才真正踏实了。
3.4 大模型推理的额外配置
很多人接 WSL2 不只是为了训练模型，更是为了本地跑大模型推理，比如 LLaMA 系列、Qwen 系列。这类场景我建议直接装 Ollama，它是目前把大模型本地化做得最省心的工具之一。
curl -fsSL https://ollama.com/install.sh | sh安装完成以后，拉取一个适合你显卡显存的模型。实时来说，8GB 显存建议用 7B 量级的量化模型，16GB 显存可以尝试 13B 甚至 32B 的四位量化模型：
ollama run qwen2.5:7bOllama 本身会自动检测 WSL2 里的 CUDA 环境，不需要额外配置。我第一次在 WSL2 里跑通 7B 模型对话时，生成速度和双系统下几乎一样，那一刻真的觉得 WSL2 值得折腾。
如果你要做更精细的推理部署，比如用 vLLM 做批量推理或提供 OpenAI 兼容 API，那就需要在 WSL2 里额外装 vLLM。这一步建议用pip install vllm，但在编译过程中会有一些底层依赖需要 C 编译器，前面让你装的 build-essential 就是在这时候派上用场的。
4. 开发体验优化技巧
4.1 文件系统的性能陷阱
WSL2 有一个非常容易被忽视的坑：跨文件系统访问的性能极差。我见过很多人把代码放在 Windows 的D:\projects目录下，然后在 WSL2 里直接访问/mnt/d/projects，结果训练时加载数据慢得离谱，还以为是 GPU 直通没生效。
原因是 WSL2 访问/mnt/d的 Windows 文件系统时，要经过 9P 协议转换，I/O 开销巨大。而数据密集型任务中最耗时的恰恰是大量小文件的随机读取，这个场景下 9P 的瓶颈尤其明显。
解决思路很简单：所有代码和数据集一定要放在 WSL2 自己的文件系统里，也就是~/路径下。Windows 侧的文件复制到 WSL2 我的习惯用法：
cp -r /mnt/d/datasets /home/username/datasetsWSL2 访问自己的 ext4 文件系统时，速度几乎等同宿主机直读。我在实际测试中，用同样的数据集做图像分类训练，放在/mnt/d下每轮 epoch 耗时 180 秒，挪到~/datasets后直接降到 95 秒，差距就是这么悬殊。
4.2 把 WSL2 迁移到 D 盘
很多人的 C 盘是固态硬盘，空间本来就不宽裕。WSL2 的虚拟磁盘文件（一个 vhdx 后缀的镜像文件）动辄二三十 GB，如果装了 CUDA、PyTorch 再拉几个模型，轻松突破 50GB。把 WSL2 迁移到其他盘符，是必须掌握的技能。
迁移前先关闭 WSL2：
wsl --shutdown然后导出当前发行版到镜像文件：
wsl --export Ubuntu-22.04 D:\wsl_backup\ubuntu2204.tar这一步根据系统体积大小会耗时几分钟到十几分钟。导出完成后，可以注销原来的发行版：
wsl --unregister Ubuntu-22.04注意：unregister 会删除原系统的虚拟磁盘文件，执行前确认自己的数据已经导出备份好了。最后重新导入到新的目录：
wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl_backup\ubuntu2204.tar --version 2导入后默认会以 root 用户进入，并且默认用户不是原来的用户名。修改方式是在 WSL2 里编辑/etc/wsl.conf，加入：
[user] default=username这里的username替换成你原来的 Linux 用户名。改完执行wsl --shutdown再重新启动，就能回到原来的用户环境。
4.3 VS Code 连接与 Python 解释器配置
开发 AI 项目离不开一个趁手的编辑器。VS Code 的 Remote-WSL 扩展是我现在使用频率最高的组合，它不需要 SSH，不需要额外配置，直接就能在本地窗口里打开 WSL2 内的项目目录。
安装步骤只有两步：在 Windows 的 VS Code 里装WSL扩展（扩展 ID 是ms-vscode-remote.remote-wsl），然后在任意 WSL2 终端里执行：
code /path/to/projectVS Code 会自动启动一个连接到 WSL2 的窗口，这个窗口里所有操作都发生在 Linux 环境内。你打开的终端是 bash，你安装的 Python 解释器是 Linux 版本，甚至连断点调试走的都是 WSL2 的进程。
这里有个细节要注意：VS Code 的 Python 解释器选择。底部状态栏点一下 Python 版本号，选择你创建的那个 venv 路径/home/username/ai-env/bin/python。如果不手动指定，VS Code 可能会自动选系统 Python，导致你 pip 装好的 torch 在编辑器里报找不到模块。
配合 Jupyter 插件的体验也值得一提。你在 WSL2 里打开一个.ipynb文件，选好 Python 内核后，每个 cell 的代码都直接跑在 Linux 环境里，GPU 资源同样可用。这比我在 Windows 原生跑 Jupyter 时碰到的各种路径分隔符、环境变量问题干净太多了。
4.4 内存和 CPU 限制
WSL2 默认不是无限使用宿主机内存的。它默认分配的是宿主机总内存的 50%，或者 8GB，取两者中较小的一个。跑大模型或者做训练时，这个默认值很可能不够用，尤其是你怎么调都感觉 WSL2 里的程序总是 OOM 的时候。
解决方案是在 Windows 用户目录下创建一个.wslconfig文件，比如C:\Users\你的用户名\.wslconfig，内容类似：
[wsl2] memory=16GB processors=8 swap=8GB localhostForwarding=true改完以后执行wsl --shutdown再重启 WSL2 才能生效。这里的memory是 WSL2 可用内存上限，processors是可用 CPU 核心数，swap是 WSL2 自己的交换空间大小，相当于 Linux 的交换分区。
我个人建议，如果宿主机是 16GB 内存，WSL2 分配 12GB 左右会比较平衡，留 4GB 给 Windows 侧开浏览器和编辑器。如果是 32GB 内存，直接分配 24GB，基本上能满足大部分本地大模型的需求。swap 也不用设得太大，SSD 交换速度比内存慢太多，swap 只是用来防止 OOM，真到了频繁写 swap 的地步，说明显存或内存规划本身出问题了。
5. 常见问题与排查实录
5.1 “WSL2 尚未准备就绪”怎么处理
这个报错是我被问过最多的问题，也是 WSL2 部署里最容易出状况的一环。通常在初次执行wsl --install之后，或者 Windows 更新之后出现。根因多半是 WSL2 内核没有正确安装或更新。
先试试手动更新内核：
wsl --update如果这条命令卡住不动，多半是网络问题。可以检查一下 Windows Update 服务是否正常运行，或者干脆去微软官方 GitHub 仓库下载 WSL2 内核安装包（.msi文件），手动安装。下载后双击运行，安装完成后重新打开 WSL2 终端。
还有一个隐蔽的原因：Windows 功能里“虚拟机平台”没有完全启用。在 PowerShell 管理员模式运行：
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启电脑。这个功能是 WSL2 的底层依赖，缺了它一切 WSL2 内核都起不来。
5.2 “无法启动，因为此计算机上未启用虚拟化”
这个报错几乎都和 BIOS 虚拟化开关有关，但有意思的是，很多人的机器其实已经开了虚拟化，问题出在 Windows 的“内核隔离”或“基于虚拟化的安全”和现有的虚拟机功能冲突。
排查步骤我建议按顺序来：
第一步，打开任务管理器，切到“性能”标签，看“虚拟化”一栏是否显示“已启用”。如果显示“已禁用”，重启进 BIOS，找 Intel Virtualization Technology 或者 SVM Mode，开启后保存退出。
第二步，检查 Windows 可选功能。控制面板 → 程序 → 启用或关闭 Windows 功能，确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”两个勾选框都打勾了。这里有一点容易让人困惑：Hyper-V 不勾选其实没关系，WSL2 并不需要完整的 Hyper-V 角色，只需要虚拟化平台这一层。
第三步，如果前两步都没问题，检查 Windows 设置里的“内核隔离”。在 Windows 安全中心 → 设备安全性 → 内核隔离设置里，把“内存完整性”关闭，然后重启。这个功能有时会干扰 Hyper-V 层的运行。我在某台笔记本上就碰到过这个问题，关掉内存完整性后 WSL2 立刻正常启动。
5.3 GPU 无法识别：nvidia-smi 报错
本来nvidia-smi好好的，某天打开 WSL2 却发现找不到 GPU 了。这种事我在 Win11 的系统更新后踩过好几次，原因基本都是 Windows 驱动更新被 Windows Update 自动替换成了不兼容 WSL2 的版本。
排查思路：先在 Windows 的 PowerShell 里跑一下nvidia-smi，如果 Windows 侧也报找不到 GPU，说明 Windows 驱动本身出了问题，重装 NVIDIA 驱动即可。
如果 Windows 侧正常，WSL2 侧报错，那就是 WSL2 的驱动转发层出了问题。最直接的修复方法是完全重启 WSL2：
wsl --shutdown然后再启动 WSL2。如果还不行，检查 Windows 驱动的版本，在 WSL2 里跑nvidia-smi时，它会显示 Windows 驱动版本号，这个版本号必须大于 470.76，否则 WSL2 的 CUDA 转发根本不可用。我在别人机器上还见过一种特殊情况：Windows 侧同时装了 NVIDIA 的 DCH 驱动和标准版驱动，两个驱动程序互相覆盖，导致 WSL2 的 GPU 接口找不到设备，卸载其中一个驱动后就好了。
5.4 内存溢出与系统假死
WSL2 里跑大模型加载时，系统突然卡死，鼠标都动不了，这个场景相信不少人都遇到过。出现这种问题的本质是：你给 WSL2 分配的内存上限设置太大，Windows 侧自身可用内存不足，而 Windows 在极端内存压力下会频繁触发 swap，导致整个系统假死。
我的建议是，如果你只有 16GB 内存还想跑 13B 模型，别硬撑。要么换更小的量化模型，要么把.wslconfig里的 memory 调低一点，给 Windows 留 4GB 保命。模型虽然大了需要更多内存，但系统假死的代价是模型进度毫无价值地丢掉了，得不偿失。
还有一个相关的细节：WSL2 的 vhdx 虚拟磁盘增长到很大后，就算删除了里面的文件，磁盘文件也不会自动缩小。这会导致 C 盘可用空间不断下降。定期清理大文件后，可以用命令压缩虚拟磁盘，在 Windows PowerShell 里：
wsl --shutdown diskpart然后在 diskpart 里选择虚拟磁盘文件所在路径，执行compact vdisk，手动压缩磁盘空间。
5.5 时间不同步和文件权限问题
WSL2 有几个算不上大故障但很影响体验的小问题。
系统时间不同步。如果你在 WSL2 里跑训练时发现日志时间滞后，或者 Git 提交的时间戳不对，多半是 WSL2 的时钟跟 Windows 宿主脱节了。重启 WSL2 就会解决，或者用sudo hwclock -s强制同步。这个问题不影响模型训练，但会影响你对比日志和版本管理，建议碰到了就顺手处理一下。
还有Exec format error这类奇怪的报错。如果你尝试在 WSL2 里运行一个.exe文件或者 Windows 侧的程序，会报这个错。反过来，在 Windows 终端里直接运行 Linux 的二进制文件也会。这是架构限制，不是出 bug 了，需要把文件复制到对的环境里再运行。
文件权限的问题也值得一提。你把 Windows 文件cp到 WSL2 后，文件权限默认可能变成-rwxrwxrwx，这不是什么问题。反过来，你在 WSL2 里创建的脚本，拿到 Windows 侧运行时，可能会因为行尾符差异报错。我的习惯是，所有脚本和配置文件都在 WSL2 里用nano或vim编辑，别在 Windows 的记事本里改，这样能避免行尾符引发的各种诡异问题。
末尾，分享一些个人体会
我用了大半年 WSL2 做 AI 开发，踩过不少坑，从驱动问题到文件系统性能陷阱都经历过。要说最值得记住的一点，就是“别把 Windows 的习惯带进 WSL2”——代码放 Linux 侧，驱动只装 Windows 侧，环境隔离用 venv，大模型分配内存留余地。这套组合下来，WSL2 的稳定性和性能已经让我彻底放弃了双系统。
最后分享一个小技巧：装完 WSL2 以后，建议立刻在~/.bashrc里加一条alias ws='wsl --shutdown'，以后碰到任何 WSL2 里的诡异问题，先执行ws重启一下，能解决八成的问题。这个习惯帮我省下了大量排查时间，希望也能帮到你。
