1. 为什么现在必须认真对待 WSL2 的 AI 开发环境部署最近在几个技术交流群里几乎每天都有人问“能不能在 Windows 上跑 PyTorch 训练模型又不想装双系统”“用 WSL2 跑 Llama.cpp 怎么显存还是被识别成 0”“明明装了 CUDAnvidia-smi 在 WSL2 里就是不显示 GPU”。这些问题背后不是配置没点对而是很多人还没真正理解 WSL2 在 AI 开发场景中扮演的角色——它早已不是那个只能跑 bash 命令的“Linux 子系统”而是一个具备内核级隔离能力、支持设备直通、可承载完整深度学习工作流的生产级开发沙盒。关键词“WSL2 部署 AI 开发环境内核级 Linux GPU 直通”里的每一个词都指向一个关键事实这不是模拟不是兼容层也不是 Docker 容器那种用户态隔离。WSL2 运行的是一个轻量级、专为 Windows 优化的完整 Linux 内核5.10.16.3它通过 Hyper-V 的轻量虚拟化机制在 Windows 主机与 Linux 环境之间建立了一条低开销、高保真的通信通道。而“GPU 直通”四个字正是这个通道能力的终极体现——NVIDIA 自 2021 年底起正式支持 WSL2 的 CUDA 工具链微软随后在 Windows 11 22H2 及后续版本中将 GPU 支持从“实验性”转为“稳定可用”这意味着你不再需要在 Linux 和 Windows 之间反复切换也不必为调试一个 CUDA kernel 而重启进 Ubuntu 系统。你可以在 VS Code 里写 Python用 Windows 的 Chrome 查论文同时让 WSL2 中的 PyTorch 直接调用本机 RTX 4090 的全部 24GB 显存中间没有虚拟化损耗没有驱动桥接层只有干净的、接近原生的 GPU 访问路径。这个方案特别适合三类人第一类是高校实验室的学生和青年研究者他们主力机是 Windows 笔记本比如搭载 RTX 4070 的移动工作站但课程作业、论文复现实验、小规模模型微调又高度依赖 Linux 生态Conda、PyTorch Lightning、Hugging Face Datasets第二类是企业中的算法工程师团队协作基于 GitLab CI/CD本地开发需复现 CI 环境而公司 IT 策略强制使用 Windows 统一桌面第三类是跨平台工具开发者比如在做 LangChain 插件或 LLM 应用前端时既要调试 Windows 下的 Electron 渲染进程又要实时验证后端模型服务的响应延迟和显存占用。对他们来说“WSL2 GPU 直通”不是炫技而是把开发效率从“能跑通”拉升到“可量产”的分水岭。我去年帮某高校一个 NLP 小组迁移开发流程他们原来用 VirtualBox 装 Ubuntu 虚拟机跑 BERT 微调单次 epoch 要 8 分钟换成 WSL2 后同样代码、同样数据集降到 2 分 17 秒——这减少的 5 分多钟不是靠参数调优而是靠绕过了整个虚拟化 I/O 栈。当然这条路也有门槛。它不像安装 Anaconda 那样点下一步就行你需要对 Windows 系统底层、Linux 内核机制、GPU 驱动协同有基本共识。但好消息是只要按正确顺序操作避开那几个经典陷阱整个过程可以控制在 40 分钟内完成且一次成功、长期稳定。接下来我会拆解每一个环节背后的原理、实操细节、参数依据以及我在 17 个不同硬件组合从 RTX 3050 笔记本到 A100 服务器节点上踩过的坑和总结出的速查口诀。2. 整体架构设计与方案选型逻辑2.1 为什么不是 WSL1为什么不是 Docker Desktop为什么不是 Hyper-V 虚拟机在动手之前必须明确我们选择 WSL2是经过横向对比后做出的工程权衡结果而非盲目跟风。下面这张表是我过去两年在 32 个真实项目中记录的性能与体验对比数据单位秒测试任务为torch.bmm1024×1024×1024 张量乘法重复 100 次取中位数环境平均耗时文件 I/O 延迟msCUDA 可见性多卡支持Windows GUI 兼容性WSL112.40.8❌ 不支持❌✅X11 转发WSL2无 GPU3.11.2❌❌✅Wayland/X11WSL2GPU 直通1.91.3✅nvidia-smi 正常✅需手动绑定✅需额外配置Docker DesktopWSL2 backend2.72.1✅但需挂载驱动⚠️ 有限需 --gpus all❌GUI 需额外网络Hyper-V 虚拟机Ubuntu 22.044.83.9✅需 GPU passthrough✅复杂配置✅RDP这张表揭示了三个核心结论第一WSL2 的 CPU 和内存性能已无限接近原生其瓶颈不在计算本身而在 I/O 和设备访问路径。这也是为什么 WSL1 在纯 CPU 任务上有时反而更快——它没有虚拟化开销但代价是彻底放弃 GPU 和现代 Linux 内核特性如 cgroups v2、overlayfs。第二Docker Desktop 虽然封装了 WSL2但它在 GPU 支持上做了二次抽象导致 CUDA 初始化多一层上下文切换实测比原生 WSL2 慢 42%更重要的是它把所有容器都塞进同一个 WSL2 发行版实例里一旦某个容器崩溃可能拖垮整个开发环境。第三Hyper-V 虚拟机看似更“正规”但它的 GPU 直通需要关闭 Windows 图形加速、禁用安全启动、手动配置 PCI 设备 ID 绑定且每次 Windows 更新后大概率失效——我曾在一个客户现场花 6 小时修复因 Windows 11 23H2 更新导致的 GPU passthrough 失败问题而 WSL2 的 GPU 支持是微软和 NVIDIA 联合维护的驱动栈更新后自动适配。所以我们的架构设计原则非常清晰以 WSL2 为唯一运行时载体Linux 发行版选用 Ubuntu 22.04 LTS长期支持、CUDA 兼容性最佳GPU 驱动由 Windows 主机统一管理WSL2 内仅安装 CUDA Toolkit 运行时非完整驱动CUDA 版本严格匹配主机驱动所支持的最高版本。这个设计规避了驱动冲突、版本错配、权限越界三大雷区也是微软官方文档《WSL2 GPU Support》中明确推荐的部署模式。2.2 “内核级 Linux”到底意味着什么它和传统虚拟机的本质区别在哪很多初学者会混淆“WSL2 内核”和“Linux 发行版内核”。这里必须划清界限WSL2 使用的是微软定制的轻量级 Linux 内核源码公开于 github.com/microsoft/WSL2-Linux-Kernel它不是从 Ubuntu 或 Debian 源码编译而来而是基于上游 Linux 5.10 分支裁剪移除了所有与硬件直接交互的模块如 ext4 文件系统驱动、PCIe 控制器驱动只保留进程调度、内存管理、网络协议栈、cgroups、namespaces 等核心子系统。这个内核被打包成一个约 50MB 的wsl2kernel文件由 Windows 的wsl.exe进程加载启动运行在 Hyper-V 的轻量 VM 中。而你通过wsl --install安装的 Ubuntu只是运行在这个内核之上的一个用户空间发行版——它的/lib/modules目录是空的lsmod命令永远返回空你无法insmod任何内核模块。这意味着你不能在 WSL2 里编译 NVIDIA 驱动.ko文件因为没有内核构建环境你不能启用nvidia-uvm统一虚拟内存模块因为该模块依赖主机内核但你可以调用nvidia-smi因为 WSL2 通过一个叫nvidia-container-cli的代理进程将命令转发给 Windows 主机上的nvlddmkm.sys驱动并将结果序列化回传。这种“内核与用户空间分离”的设计正是 WSL2 稳定性的基石。当你的 Windows 主机升级到新版本驱动WSL2 内无需重装任何东西只要wsl --update同步内核即可。我见过太多人在 Ubuntu 虚拟机里折腾nvidia-driver-535编译失败最后发现是内核头文件版本不匹配而在 WSL2 中这个问题根本不存在——驱动在 Windows 层内核在 WSL2 层二者通过定义良好的 ABI 接口通信就像两个微服务通过 gRPC 交互一样解耦。2.3 GPU 直通的技术实现路径从 Windows 驱动到 PyTorch 的全链路“GPU 直通”这个词容易让人联想到物理设备独占但在 WSL2 场景下它的真实含义是Windows 主机上的 NVIDIA 驱动通过 WDDMWindows Display Driver Model与 WSL2 的 Linux 内核之间建立了一条专用的、零拷贝的 GPU 命令通道。这条通道不经过 Windows 图形子系统也不走 PCIe 总线模拟而是利用 Hyper-V 的 VMBus虚拟机总线直接传递 GPU 指令缓冲区。整个数据流向如下PyTorch 在 WSL2 中调用torch.cuda.is_available()→ 触发libcuda.so加载libcuda.soWSL2 版本向nvidia-container-cli发送初始化请求nvidia-container-cli通过 WSL2 的ioctl接口将请求转发至 Windows 主机的nvapi64.dllnvapi64.dll调用nvlddmkm.sys驱动分配 GPU 上下文并返回设备句柄WSL2 内的 CUDA 运行时缓存该句柄后续所有 kernel launch、memory copy 操作均通过此句柄直达 GPU。这个链路的关键在于第 3 步和第 4 步之间的 ABI 兼容性。NVIDIA 官方要求WSL2 中安装的 CUDA Toolkit 版本必须 ≤ Windows 主机驱动所支持的最高 CUDA 版本。例如如果你的 Windows 驱动是 535.98支持 CUDA 12.2那么 WSL2 中只能安装 CUDA 12.2 或更低版本如 12.1、11.8绝不能装 12.3。这个限制不是软件故意设障而是因为nvlddmkm.sys导出的函数符号表在不同 CUDA 版本间有细微变化强行混用会导致dlopen失败或段错误。我曾在一个项目中因忽略此规则导致import torch报undefined symbol: cuGraphAddKernelNode排查了两天才发现是 CUDA 版本越界。因此我们的部署流程必须包含一个强制校验步骤先查 Windows 驱动版本再反推可安装的 CUDA 版本最后下载对应.run安装包。这个顺序不能颠倒否则所有后续操作都是空中楼阁。3. 核心细节解析与实操要点3.1 硬件与系统前提条件哪些配置是硬性门槛不是所有 Windows 设备都能开启 WSL2 GPU 支持。根据 NVIDIA 官方文档和我实测的 27 台设备清单以下五项是不可协商的硬性前提Windows 版本 ≥ Windows 11 21H2 或 Windows 10 21H2Build 19044Windows 10 20H2Build 19042虽支持 WSL2但 GPU 直通需 KB5004237 补丁且仅限部分 OEM 设备Windows 11 22H2 是首个将 WSL2 GPU 支持标记为“稳定”的版本建议直接升级。CPU 必须支持虚拟化Intel VT-x / AMD-V且 BIOS 中已启用在 Windows 中打开任务管理器 → 性能 → CPU右下角查看“虚拟化”是否为“已启用”若显示“已禁用”需重启进 BIOS通常按 F2/F12/Del找到Intel Virtualization Technology或SVM Mode并设为 Enabled。GPU 必须是 NVIDIA GeForce RTX 20 系列及以上或 Quadro/Tesla A 系列GTX 10 系列Pascal 架构完全不支持RTX 30 系列Ampere支持 CUDA 11.xRTX 40 系列Ada Lovelace需驱动 ≥ 528.49 才支持 CUDA 12.xAMD 和 Intel 核显目前不支持WSL2 GPU 直通截至 2024 年 6 月。Windows 主机驱动版本 ≥ NVIDIA Game Ready Driver 515.65.01 或 Studio Driver 516.94这是 CUDA 11.7 的最低要求低于此版本的驱动如 472.12无法与 WSL2 通信驱动必须从 NVIDIA 官网 下载OEM 厂商预装驱动如 Dell、Lenovo往往滞后需手动覆盖。WSL2 内核版本 ≥ 5.10.16.3运行wsl --list --verbose查看当前内核版本若低于此版本执行wsl --update升级注意wsl --update默认升级到最新稳定版但某些新内核如 5.15.x与旧驱动存在兼容问题此时需指定版本wsl --update --rollback回退或wsl --update --default-version 2强制重装。提示以上五项缺一不可。我曾遇到一个案例某用户 RTX 4090 Windows 11 23H2 最新驱动但 BIOS 中虚拟化被禁用导致wsl --install后nvidia-smi始终报NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver。这种问题不会报错只会静默失败必须逐项人工核验。3.2 WSL2 发行版选型为什么 Ubuntu 22.04 是当前最优解虽然 WSL2 支持数十种 Linux 发行版但 AI 开发场景下Ubuntu 22.04 LTSJammy Jellyfish是经过千锤百炼的首选。原因有三第一CUDA Toolkit 官方预编译包的默认目标平台。NVIDIA 提供的cuda_12.2.0_535.54.03_linux.run安装脚本默认检测/etc/os-release中的IDubuntu和VERSION_ID22.04。若你装的是 Arch 或 Fedora安装程序会报Unsupported distribution并退出。虽然可通过--override参数强制安装但后续的libcudnn8、libcublas11等依赖包可能因 glibc 版本不匹配而无法解析。第二Python 生态兼容性最成熟。Hugging Face Transformers、Lightning、DeepSpeed 等主流库的 CI 流程均以 Ubuntu 22.04 为基准测试环境。例如deepspeed的 wheel 包在 PyPI 上只提供cp310-cp310-manylinux_2_31_x86_64.whl对应 glibc 2.31而 Ubuntu 22.04 的 glibc 版本正是 2.35向下兼容CentOS Stream 9 的 glibc 2.34 则可能触发ImportError: libcublas.so.11: cannot open shared object file。第三系统资源占用最低。我用systemd-analyze blame对比了 5 种发行版的启动耗时单位msUbuntu 22.04321 msDebian 12417 msCentOS Stream 9589 msArch Linux632 msAlpine 3.18289 ms但无 systemdCUDA 依赖缺失Alpine 虽快但其 musl libc 与 CUDA 的 glibc 二进制不兼容直接排除。Ubuntu 22.04 在速度、兼容性、社区支持三者间取得了最佳平衡。安装命令极其简单# 启用 WSL 功能管理员 PowerShell dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart # 重启后设置 WSL2 为默认版本 wsl --set-default-version 2 # 安装 Ubuntu 22.04从 Microsoft Store 或命令行 wsl --install -d Ubuntu-22.04注意不要使用wsl --install一键安装因为它默认装 Ubuntu 20.04Focal而 20.04 的 glibc 2.31 与 CUDA 12.2 的二进制不完全兼容会导致torch.compile()报undefined symbol: __cxa_throw_bad_array_new_length。务必显式指定-d Ubuntu-22.04。3.3 CUDA Toolkit 安装精确匹配驱动版本的实操方法这是整个部署中最容易出错的环节。很多人直接下载 CUDA 12.2 官网安装包一路下一步结果nvidia-smi能用nvcc --version能显示但import torch就 segmentation fault。根源在于你安装的 CUDA Toolkit 版本与 Windows 主机驱动所声明的 CUDA 兼容版本不一致。正确做法是“逆向查询”先查驱动再定 CUDA。步骤 1在 Windows 主机上确认驱动版本和 CUDA 支持上限打开nvidia-smiWindows 命令提示符顶部显示驱动版本如Driver Version: 535.98访问 NVIDIA 驱动 CUDA 兼容表 查表得驱动 535.98 支持 CUDA 最高版本为12.2确切说是 12.2.0非 12.2.1。步骤 2在 WSL2 中下载并安装严格匹配的 CUDA Toolkit进入 WSL2wsl -d Ubuntu-22.04下载 CUDA 12.2.0注意是 .0不是 .1wget https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run sudo sh cuda_12.2.0_535.54.03_linux.run --silent --override --toolkit --toolkitpath/usr/local/cuda-12.2关键参数说明--silent静默安装不弹出图形界面--override绕过发行版检查Ubuntu 22.04 在白名单内此参数可省略但加上更保险--toolkit只安装 CUDA Toolkit不装驱动WSL2 中禁止装驱动--toolkitpath指定安装路径避免与系统默认/usr/local/cuda冲突。步骤 3配置环境变量永久生效编辑~/.bashrc追加export CUDA_HOME/usr/local/cuda-12.2 export PATH$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH$CUDA_HOME/lib64:$LD_LIBRARY_PATH然后source ~/.bashrc。实操心得我曾在一个客户现场因下载了cuda_12.2.1_535.86.10_linux.run驱动 535.86 支持的版本导致 PyTorch 2.0.1 的torch._C模块加载失败。后来发现12.2.1 的libcudart.so.12与 12.2.0 的符号表有微小差异。教训是宁可降级绝不越界。如果驱动是 535.54就只装 12.2.0如果驱动是 528.49RTX 40 系列就装 12.1.0。3.4 PyTorch 与 cuDNN 的精准安装避免 ABI 冲突的黄金法则CUDA Toolkit 只是基础运行时PyTorch 才是 AI 开发的核心。而 PyTorch 的 GPU 支持依赖于cuDNNCUDA Deep Neural Network library——一个高度优化的神经网络原语库。它的安装必须遵循“ABI 锁定”原则PyTorch 版本、CUDA 版本、cuDNN 版本三者必须构成官方预编译 wheel 的标准三元组。以 PyTorch 2.1.0 为例其官方 wheel 包命名格式为torch-2.1.0cu121-cp311-cp311-linux_x86_64.whl其中cu121表示编译时链接的 CUDA 12.1cp311表示 Python 3.11。因此我们的安装策略是先确定 PyTorch 版本再反查其对应的 CUDA/cuDNN 组合最后安装匹配的 wheel。实操步骤查 PyTorch 官网 Download Page 选择OS: LinuxPackage: PipLanguage: PythonCompute Platform: CUDA 12.1因为我们装的是 CUDA 12.2.0但 PyTorch 2.1.0 的cu121wheel 兼容 CUDA 12.2这是 NVIDIA 的 ABI 向后兼容保证复制生成的 pip 命令pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121执行安装确保 pip 已升级python3 -m pip install --upgrade pip pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121为什么不用 condaConda 的pytorch::pytorch包在 WSL2 中常因libcudnn.so.8路径解析失败而报错。pip wheel 是二进制分发路径硬编码稳定性更高。我测试过 12 个不同 conda 环境7 个出现OSError: libcudnn.so.8: cannot open shared object file而 pip 方式 100% 成功。cuDNN 是否需要单独安装不需要。PyTorch 的 wheel 包已静态链接libcudnn.so.8解压 wheel 可见torch/lib/libcudnn.so.8。单独安装 cuDNN 反而可能导致版本冲突。唯一例外是使用DeepSpeed时它需要libcudnn_ops_infer.so.8此时才需从 NVIDIA cuDNN 下载页 获取对应 CUDA 版本的 tar.gz解压后sudo cp -P cudnn-*-archive/include/cudnn*.h /usr/local/cuda-12.2/include和sudo cp -P cudnn-*-archive/lib/libcudnn* /usr/local/cuda-12.2/lib64。4. 实操过程与核心环节实现4.1 全流程实操记录从空白 Windows 到可训练模型的 38 分钟以下是我上周在一个全新 Windows 11 22H2 笔记本i7-12800H RTX 4070 Laptop上的完整操作记录时间戳精确到秒所有命令均可直接复制粘贴T00:00 - 启用 WSL 功能管理员 PowerShell# 执行后重启 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestartT01:22 - 重启后升级 WSL2 内核并安装 Ubuntu 22.04# 管理员 PowerShell wsl --update wsl --set-default-version 2 wsl --install -d Ubuntu-22.04 # 等待安装完成设置用户名密码T05:18 - 进入 WSL2更新系统并安装基础工具wsl -d Ubuntu-22.04 sudo apt update sudo apt upgrade -y sudo apt install -y build-essential python3-pip python3-dev git curl wget vimT08:45 - 下载并安装 CUDA 12.2.0驱动 535.98wget https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run sudo sh cuda_12.2.0_535.54.03_linux.run --silent --override --toolkit --toolkitpath/usr/local/cuda-12.2 echo export CUDA_HOME/usr/local/cuda-12.2 ~/.bashrc echo export PATH$CUDA_HOME/bin:$PATH ~/.bashrc echo export LD_LIBRARY_PATH$CUDA_HOME/lib64:$LD_LIBRARY_PATH ~/.bashrc source ~/.bashrcT12:33 - 验证 CUDA 安装nvcc --version # 应输出 release 12.2, V12.2.0 nvidia-smi # 应显示 GPU 名称、温度、显存使用此时为 0%T13:05 - 安装 PyTorch 2.1.0 cu121python3 -m pip install --upgrade pip pip3 install torch2.1.0cu121 torchvision0.16.0cu121 torchaudio2.1.0cu121 --index-url https://download.pytorch.org/whl/cu121T16:42 - 验证 PyTorch GPU 支持python3 -c import torch print(CUDA available:, torch.cuda.is_available()) print(CUDA version:, torch.version.cuda) print(GPU count:, torch.cuda.device_count()) print(Current device:, torch.cuda.get_current_device()) print(Device name:, torch.cuda.get_device_name(0)) a torch.randn(1000, 1000).cuda() b torch.randn(1000, 1000).cuda() c torch.mm(a, b) print(Matrix multiply OK, result shape:, c.shape) 预期输出CUDA available: True CUDA version: 12.1 GPU count: 1 Current device: 0 Device name: NVIDIA GeForce RTX 4070 Laptop GPU Matrix multiply OK, result shape: torch.Size([1000, 1000])T18:55 - 安装 Hugging Face 生态可选但强烈推荐pip3 install transformers datasets accelerate bitsandbytesT22:10 - 运行一个真实微调脚本Qwen-1.5B LoRAgit clone https://huggingface.co/Qwen/Qwen1.5-0.5B cd Qwen1.5-0.5B # 创建 train.py内容略标准 Trainer 脚本 python3 train.pyT38:00 - 观察 nvidia-smi 输出显存占用从 0% 跃升至 62%训练日志滚动loss 下降整个过程耗时 38 分钟无报错无回退。关键成功标志是torch.cuda.is_available()返回True且nvidia-smi在 WSL2 中能实时反映显存变化——这证明 GPU 直通链路已打通。4.2 多 GPU 支持如何让 WSL2 识别并使用多张显卡WSL2 默认只暴露 Windows 主机上“活动”的那张 GPU。如果你的台式机插了两张 RTX 4090但 Windows 显示设置中只将主显示器接在卡 A 上那么 WSL2 中nvidia-smi只会显示卡 A。要启用多卡需两步操作步骤 1在 Windows 中启用所有 GPU 的“计算模式”打开 NVIDIA 控制面板 → 管理 3D 设置 → 程序设置 → 添加wsl.exe将“CUDA - GPUs”设为“All”更关键的是打开 PowerShell管理员执行# 查询所有 GPU 设备 ID Get-WmiObject Win32_VideoController | Where-Object {$_.Name -like *NVIDIA*} | Select-Object Name, PNPDeviceID # 假设输出PCI\VEN_10DEDEV_2684SUBSYS...卡 A、PCI\VEN_10DEDEV_2684SUBSYS...卡 B # 为每张卡启用计算模式需重启 WSL2 wsl --shutdown步骤 2在 WSL2 中验证多卡可见性nvidia-smi -L # 应输出两行GPU 0: ... , GPU 1: ... python3 -c import torch; print([torch.cuda.get_device_name(i) for i in range(torch.cuda.device_count())])PyTorch 多卡训练代码示例DataParallelmodel YourModel().cuda() if torch.cuda.device_count() 1: model torch.nn.DataParallel(model) # 自动分配到所有 GPU # 后续训练逻辑不变注意torch.distributed的nccl后端在 WSL2 中尚不完全稳定建议生产环境优先用DataParallel。我测试过 4 卡 A100 集群DataParallel的扩展效率达 3.6x足够日常使用。4.3 VS Code 远程开发集成在 Windows 界面里写 Linux 代码这是 WSL2 AI 开发的最大体验优势——你不需要离开熟悉的 Windows 桌面。VS Code 的 Remote-WSL 插件让你在 Windows 下打开一个文件夹实际编辑的是 WSL2 中的文件终端运行的是 WSL2 的 bash调试器连接的是 WSL2 的 Python 进程。安装步骤Windows 中安装 VS Code官网下载安装扩展 “Remote - WSL”打开命令面板CtrlShiftP输入WSL: New Window在新窗口中按 Ctrl 打开集成终端自动进入 WSL2cd到你的项目目录code .重新在当前窗口打开文件夹。此时所有操作都在 WSL2 环境中CtrlShiftP→Python: Select Interpreter→ 选择/usr/bin/python3创建launch.json调试配置console: integratedTerminal断点调试、变量监视、GPU 内存