在 Windows 上写代码的人早晚会碰到 WSL 这道坎。有人拿它当能跑 gcc 的终端有人把整套后端服务、Docker、GPU 训练环境都搬进去还有人折腾半天发现自己连发行版叫什么名字都没记清。WSL 常用命令这个词被搜了无数次但绝大多数速查表只给你一张命令清单不告诉你这些命令分别作用在哪一层——是管虚拟机、管发行版还是管发行版里的 Linux 系统本身。这三个层次搞混就会出现我明明执行了命令却没有任何反应的典型困惑。下面这份东西按我自己的使用顺序来组织从装、到用、到搬家、到排错每条命令都尽量说清楚它的作用域、我为什么这么用、以及踩过的坑。适合刚打开 WSL 的新人也适合用了两年但一直是照着粘贴的老用户。1. WSL 命令的两套体系谁在管虚拟机谁在管系统很多人学 WSL 命令效率低根本原因是没建立分层的概念。WSL 一共有两个命令空间Windows 侧的wsl.exe以及配置工具wslconfig.exe和 Linux 发行版内部的常规命令。前者管的是盒子——虚拟机的创建、启动、关闭、导入导出后者管的是盒子里装了什么——进程、网络、用户、服务。你在 PowerShell 里敲ls没反应不代表 WSL 坏了只是你在错误的楼层找人。1.1 wsl.exe 管的是盒子Linux 命令管的是盒子里的东西把 WSL 想象成一排出租公寓wsl.exe是物业负责建楼--install、开门直接输入发行版名或wsl、锁门--terminate、整栋断电--shutdown、办过户--export/--import而apt、systemctl、ip、useradd这些是住户自己的家务。物业不管你家冰箱里放什么住户也没权限拆楼。这个比喻能解释一个高频现象在 Windows 终端里执行sudo、systemctl报找不到命令完全正常因为它们属于二楼。判断一条命令属于哪一层有个特别快的办法看它的参数风格。wsl.exe用的是 Windows 风格双横线长参数配短参数别名比如--list --verbose写成-l -v--distribution写成-d而 Linux 命令绝大多数是单横线短参数-a、-l、-h。这个细节在写脚本时尤其重要我曾经在.ps1脚本里把-d当成后台运行理解结果把整个发行版参数传错了排查了半小时才反应过来。1.2 三条最容易记混的命令-l、-t、--shutdown-l系列有三个变体含义完全不同这是新手最容易混淆的地方命令含义典型输出wsl -l -v列出已安装发行版及版本号、运行状态名字、State、Versionwsl -l -o列出可在线安装的发行版清单商店里可选的发行版名wsl -l -q只列出名字适合喂给脚本纯文本无表头写自动化脚本时必须用-q因为-l -v的输出里带 UTF-16 编码和一些不可见字符直接管道传给for循环会出问题。我在批处理里第一次做遍历所有发行版逐个备份时就被这个编码坑了命令行看着正常变量里却多出一堆\0。-t是--terminate的缩写作用是关掉指定发行版的所有进程但保留虚拟机基础设施不收参数时会报错必须跟-d指定名字。而--shutdown是全局断电直接终止 WSL2 轻量虚拟机本身所有发行版一起停。两者的选择标准很简单只改了某个发行版的配置需要重启它用-t改了.wslconfig、或者想彻底释放内存用--shutdown。提示改了 Windows 侧的.wslconfig之后必须wsl --shutdown才生效只-t单个发行版没用因为资源配额是虚拟机级别的。2. 装不上、装太慢、进不去安装阶段的真实卡点安装环节的绝大部分问题其实不是技术问题而是不知道命令背后发生了什么。wsl --install一条命令看着优雅实际它做了四五件事启用虚拟机平台和 WSL 可选组件、下载并安装 WSL 内核更新包、设置默认版本为 2、从分发渠道拉取一个默认发行版、然后首次启动让你创建账号。任何一步卡住表现都是命令跑完了但什么都没发生。2.1 wsl --install 到底做了什么在较新的 Windows 11 和打过补丁的 Windows 10 上wsl --install的执行路径大致是先弹 UAC 提权调用 DISM 开启Microsoft-Windows-Subsystem-Linux和VirtualMachinePlatform两个可选组件然后下载 WSL 的 MSI 分发包并安装最后从商店渠道拉取 Ubuntu。所以它需要你重启一次重启后第二次执行才会真正开始下载发行版。如果你在第一步之后直接跑去敲wsl得到的是没有已安装的发行版这不叫失败。对国内网络环境比较讲究的人来说一次装好并减少来回可以拆开做先wsl --install --no-distribution只装 WSL 本体和组件重启再用wsl --set-default-version 2明确默认版本最后单独处理发行版。这个顺序的好处是每一步都能看到明确反馈出错也知道卡在哪。我自己的新机器流程一直是这三步比一把梭省心。想看看有哪些发行版可选wsl -l -o是安全的只读操作不会触发下载。选定之后wsl --install -d Ubuntu-22.04指定版本加--no-launch可以让它装完不自动启动方便你先改配置再进系统。2.2 在线安装慢与离线导入的完整流程wsl --install慢慢点通常集中在发行版镜像下载这一段因为走的是分发渠道受网络出口影响很大。可选的应对方式有三条路按可靠性排序第一条是把 WSL 本体和发行版分开处理。WSL 本体可以从官方发布页直接下 MSI 离线包装完不会去拉发行版。第二条是用 rootfs 离线包手工导入——Ubuntu 官方会提供ubuntu-22.04-server-cloudimg-amd64-wsl.rootfs.tar.gz这类为 WSL 准备好的根文件系统包下载回来之后# 先在 Windows 本地建目录再用管理员 PowerShell 执行 wsl --import Ubuntu-22.04 D:\wsl\ubuntu2204 D:\downloads\ubuntu2204.rootfs.tar.gz --version 2这段命令的三个参数分别是发行版名字、安装位置、tar 包路径。安装位置建议放在 SSD 上的独立目录别塞在C:\Users下面一来备份方便二来以后想整体搬盘直接改路径就行。第三条路是等——如果你只是偶尔装一次其实没必要折腾。导入完成后wsl -l -v就能看到新发行版直接wsl -d Ubuntu-22.04进入。整个过程不需要登录任何账号比商店安装干净。2.3 导入之后默认用户变成 root 的修复不管你是手工--import的还是从别人那儿拷来的 tar 包导入后默认用户一定是root。这个状态能跑但长期用很危险所有文件都归 rootnpm、pip装的包权限混乱将来想切回普通用户会一地鸡毛。修复方式有两种。第一种是在首次进系统时就把用户建好# 在 WSL 里以 root 身份执行 adduser yourname usermod -aG sudo yourname然后在发行版内写/etc/wsl.conf[user] defaultyourname保存退出回到 PowerShell 执行wsl --terminate Ubuntu-22.04再进就是普通用户了。第二种是某些发行版自带的配置工具比如ubuntu2204.exe config --default-user yourname但这是旧版分发方式遗留下来的 exe用 MSI 安装的新版 WSL 里不一定存在别把宝押在它身上。注意/etc/wsl.conf的改动同样需要wsl --terminate才加载改完不重启会以为没生效然后反复改改到最后自己都懵了。2.4 your version of windows subsystem is too old 这类提示怎么处理这个报错信息很长核心意思是你的 WSL 组件版本太老不支持当前命令行用到的参数或功能。常见触发场景是你在某个较新的教程里看到了--manage、--mount这类参数但本机 WSL 还是几年前随系统预装的旧版。处理方式就是升级wsl --update如果这条命令本身也卡住或者报错可以试试wsl --update --web-download它会让 WSL 从网络分发渠道取更新绕开应用商店的更新链路。更新完成后wsl --version会打印出 WSL 版本、内核版本、WSLg 版本看到这些信息才说明你装的是独立分发版而不是系统内置的老组件。3. 路径与文件系统\wsl$、/mnt/c 和那要命的性能差跨系统路径是 WSL 使用中投诉率最高的地方没有之一。Windows 和 Linux 各自有一套路径表达方向搞反就是文件不存在位置选错就是编译要等十分钟。这一节把两个方向的写法、转换工具和性能原因一次说清。3.1 两个方向的路径写法与 wslpath 的用法从 Windows 访问 Linux 文件用 UNC 路径。老写法是\\wsl$\Ubuntu-22.04\home\yourname新写法是\\wsl.localhost\Ubuntu-22.04\...两者现在都还能用推荐用后者因为在资源管理器里更容易被识别。把它映射成网络驱动器也可以net use Z: \\wsl.localhost\Ubuntu-22.04\home\yourname但我不建议长期这么干理由下一小节讲。从 Linux 访问 Windows 文件在/mnt/下C:\Users\you\project对应/mnt/c/Users/you/project。盘符统一小写反斜杠换成斜杠空格要转义。两边互转不用手算wslpath就是干这个的wslpath -w /home/yourname/project # 输出 \\wsl.localhost\Ubuntu-22.04\home\yourname\project wslpath -u C:\Users\you\project # 输出 /mnt/c/Users/you/project wslpath -a -u C:\Users\you\a b.txt # -a 输出绝对路径处理空格更稳写脚本时用wslpath而不是字符串拼接能省掉大量转角问题。我有一段构建脚本原来硬编码/mnt/c/...同事换成D盘就全崩改成wslpath -u $WIN_PATH之后彻底解决。3.2 为什么 npm install 放在 /mnt/c 下会慢十倍这是 WSL 最值得记住的一条性能常识代码放在/mnt/c下所有文件操作都要穿过一层跨系统文件协议放在 Linux 原生文件系统比如~/projects下走的是本地 ext4。差异有多大同样是npm install一个中等规模的前端项目放在/mnt/c/Users/...下可能要三到五分钟放到~/projects下往往二十秒内结束。原因是/mnt/c的每次stat、open、readdir都要经虚拟化文件共享层转发而这类项目动辄产生几万个小文件元数据操作被放大得极其明显。Docker 构建、git status、cargo build、Python 虚拟环境创建全都有同样的十倍级差距。所以我的建议很明确源码放 Linux 侧Windows 侧只用编辑器去连它而不是把源码放 Windows 侧再从 WSL 去读。这条把性能问题一次性解决掉比你调任何参数都管用。3.3 跨系统文件权限与 metadata 选项反向的问题也存在从 Windows 那边创建的文件进到 WSL 里往往显示成777或者全归root导致ssh私钥被拒OpenSSH 对密钥文件权限非常挑剔。根因是 DrvFs 默认不带 Linux 权限元数据。解决办法是在/etc/wsl.conf的[automount]段打开 metadata[automount] enabled true root /mnt/ options metadata,umask22,fmask11这里umask22让目录默认权限变成755fmask11让文件默认变成644再把caseoff加上可以避免大小写敏感带来的诡异问题。改完wsl --shutdown重启生效。提示如果你在 Windows 侧直接编辑 WSL 里的文件注意编辑器不要用会改写换行符的模式否则你会看到一堆\r导致的bad interpreter报错。VS Code 右下角把 CRLF 切成 LF 就能避免。4. 生命周期管理关闭、重启、导出、迁移WSL 的进程模型有点反直觉只要有一个发行版在跑底层虚拟机就一直活着内存占用也会持续爬升直到你显式关掉它。很多人抱怨WSL 吃掉了我 8G 内存绝大多数情况是没有正确关闭或者不知道.wslconfig能限制它。4.1 --terminate 与 --shutdown 的区别和选择wsl --terminate 发行版名关闭指定发行版的全部进程虚拟机会在最后一个发行版被终止后自动释放。wsl --shutdown是直接对整个 WSL2 虚拟机下电所有发行版、所有后台服务立刻停。什么时候用哪个我的习惯是只是想让某个卡住的发行版重启wsl -t Ubuntu-22.04改了.wslconfig里的内存、CPU、网络模式wsl --shutdownDocker 起不来、端口映射乱掉、网络突然不通先wsl --shutdown再进八成能好关机前想腾内存wsl --shutdown顺带说一句WSL 支持自动回收内存的选项在.wslconfig里加autoMemoryReclaimgradual较新版本支持闲置一段时间后会把缓存内存还给 Windows比每次手动关省事得多。4.2 tar 导出导入实现整机搬迁WSL 最让人安心的一点是发行版可以完整打包成单个 tar 文件包括你装的所有软件、配置、数据。换电脑、重装系统、想给同事复现环境全靠这一对命令# 导出先关闭再导出避免文件被占用 wsl --shutdown wsl --export Ubuntu-22.04 D:\backup\ubuntu2204-20250101.tar # 导入到新机器新机器需先装好 WSL 本体 wsl --import Ubuntu-22.04 D:\wsl\ubuntu2204 D:\backup\ubuntu2204-20250101.tar --version 2导出前一定要--shutdown运行中导出会得到不一致的文件系统导入后可能出现莫名其妙的损坏。tar 包大小取决于你装了多少东西一个装了 CUDA 工具链的发行版轻松超过 20G所以定期清理缓存apt clean、清 pip 和 npm 缓存能让备份体积小一大截。--import的路径建议用绝对路径且目录事先建好导入后默认用户仍是 root按 2.3 节的方法处理。4.3 磁盘占用越来越大怎么收WSL2 的虚拟磁盘是个稀疏 VHDX 文件只增不减——你在里面删了 10G 文件Windows 侧看到的ext4.vhdx可能一点没小。这属于设计行为不是 bug。回收方式有几个层次。最简单的是在发行版内清理无用数据然后关闭 WSL再从 Windows 侧压缩 VHDX可以用磁盘管理工具或diskpart的compact vdisk。较新版本的 WSL 支持把磁盘设为稀疏模式wsl --manage Ubuntu-22.04 --set-sparse true这个选项能让空间在删除文件后自动归还代价是理论上存在极小的数据损坏风险所以官方加了--allow-unsafe之类的开关。我自己的做法是日常发行版开稀疏承载重要工作数据的发行版不开靠定期全量备份保平安。另外别忘了 Docker 的数据卷也在这个 VHDX 里Docker 的镜像和构建缓存经常是空间消耗的大头docker system prune -a一个月跑一次很值。5. .wslconfig 与 wsl.conf两个配置文件别搞反这两个文件名长得像、位置不同、管的事也完全不同但被搞混的频率高得离谱。一个最简单的记忆法.wslconfig在 Windows 用户目录是物业规定/etc/wsl.conf在发行版里是住户家规。5.1 .wslconfig 放在 Windows 用户目录管资源与网络完整路径是C:\Users\你的用户名\.wslconfig注意文件名前面有个点创建时别被资源管理器隐藏文件的提示搞晕。它的作用域是全局所有发行版因为它配置的是底层虚拟机。一个比较实用的配置长这样[wsl2] memory12GB processors6 swap8GB swapfileD:\\wsl\\swap.vhdx localhostForwardingtrue nestedVirtualizationtrue guiApplicationstrue [experimental] autoMemoryReclaimgradual hostAddressLoopbacktrue几个参数的实际影响值得说清楚。memory是硬上限默认值大约是物理内存的一半如果你机器有 32G 内存而 WSL 默认拿 16G同时开 Docker 和几个服务很快就吃满表现是卡到怀疑人生把它压到 12G 反而更稳因为 Windows 本身也要留空间。processors控制分配给虚拟机的逻辑核心数编译密集型任务可以给多一些但给满会让 Windows 侧明显卡顿。swap默认是按内存比例算的编译大项目时容易触发 OOM手动给到 8G 以上会舒服很多swapfile指定到非系统盘能减少 C 盘压力。nestedVirtualizationtrue是跑 Docker、KVM、模拟器这类需要嵌套虚拟化的场景必备。guiApplicationstrue让 WSL 里的图形程序能直接弹窗到 Windows 桌面跑个gedit、xeyes验证一下有没有生效。5.2 /etc/wsl.conf 放在发行版里管 systemd 与挂载这个文件在发行版内部每个发行版各有一份互不影响。典型内容[boot] systemdtrue [user] defaultyourname [interop] enabledtrue appendWindowsPathtrue [network] generateResolvConftrue [automount] enabledtrue root/mnt/ optionsmetadata,umask22,fmask11systemdtrue是近两年最重要的一个开关下面单独讲。appendWindowsPathtrue会把 Windows 的 PATH 追加到 Linux 的 PATH 里好处是能直接调code、explorer.exe、notepad.exe坏处是 Windows 那一大堆路径会让which变慢而且偶尔和 Linux 同名命令撞车。我一般保持开启但如果你发现某个命令的行为诡异先检查是不是被 Windows 版本抢占了。generateResolvConftrue会在每次启动时重新生成/etc/resolv.conf如果你手动改过这个文件发现重启就失效原因就在这儿。5.3 systemd 开启后服务类命令终于能用了早期的 WSL 没有 init 系统systemctl直接报System has not been booted with systemd。所有服务只能手动起重启发行版就全丢。开启 systemd 之后systemctl start/stop/enable全部可用Docker、Nginx、Redis、PostgreSQL 这些装在发行版里的服务终于能像正常 Linux 一样管理。开启方式就是在/etc/wsl.conf写入systemdtrue然后wsl --terminate重启进去执行systemctl is-system-running验证返回running或degraded都算正常。前置条件是 WSL 版本足够新太老的版本这个配置会被静默忽略所以升级 WSL 是第一步。一个实操经验开了 systemd 之后如果你同时用 Docker Desktop两者可能都想管理 Docker 守护进程容易出现端口冲突或状态不一致。选一条路走到底要么全用发行版内的 Docker Engine要么全用 Docker Desktop别混着来。6. 开发工具链衔接VS Code、Docker、GPU 与字体WSL 真正的价值不在终端本身而在于它能把 Linux 工具链无缝接到你熟悉的 Windows 编辑器和硬件上。这一节讲几个最常用的衔接点以及各自的前提条件。6.1 在 VS Code 里用 WSL 的正确姿势标准做法是装 Remote - WSL 扩展然后在 WSL 终端里进入项目目录敲code .。这个动作会在 WSL 内部拉起一个轻量服务端VS Code 的界面在 Windows 上渲染文件读写、终端、调试器全部在 Linux 侧执行。这样做的关键收益是文件 IO 走的是 Linux 原生文件系统打开大仓库、跑格式化、做全量搜索都不会卡。反例就是直接在 Windows 里打开\\wsl.localhost\...路径的文件夹。这种方式能用但所有文件操作都要穿跨系统协议一个CtrlShiftF全局搜索能让你等到怀疑人生。我见过同事抱怨VS Code 打开项目要两分钟换到code .之后秒开。另一个细节是终端选择。VS Code 里的集成终端默认继承 WSL 的 shell如果你用zsh配了主题和插件记得在 WSL 里把zsh设为默认 shell否则 VS Code 里跑的还是bash配置看起来没生效。6.2 终端字体怎么调出接近 macOS 的观感这是被搜得很多但讲得很少的话题。macOS 终端看起来舒服主要来自三点字体本身的字形设计、抗锯齿方式macOS 用灰度抗锯齿笔画偏粗偏圆、以及较高的字重设置。在 Windows 上想靠近这个观感可以这样配。字体选择上等宽字体里我反复用过这几款JetBrains Mono 的字形辨识度好连字处理克制Cascadia Code 是系统自带的省安装但连字偏多Maple Mono 的中英文混排处理得不错做中文注释多的项目很舒服更纱黑体Sarasa Gothic是少见的等宽中文字体方案代码和对齐的中文能同时好看。想要图标和特殊符号不出现方框选带 Nerd Font 补丁的版本。配置项上在 VS Code 的settings.json里{ editor.fontFamily: JetBrainsMono Nerd Font, 更纱等距黑体, monospace, editor.fontSize: 14, editor.fontWeight: 400, terminal.integrated.fontFamily: JetBrainsMono Nerd Font, terminal.integrated.fontWeight: 400, terminal.integrated.fontWeightBold: 600, terminal.integrated.lineHeight: 1.2, terminal.integrated.letterSpacing: 0.2 }几个参数的作用fontWeight调到 400 比默认的 normal 更接近 macOS 那种厚实感lineHeight给到 1.2 到 1.3 让行间透气letterSpacing加一点点能明显缓解中文和英文挤在一起的问题。如果你用 Windows Terminal 而不是 VS Code 集成终端对应的设置在它自己的 JSON 配置里antialiasingMode选grayscale比默认的cleartype更接近 macOS 的渲染味道fontWeight同样建议调上去。字体装完记得彻底重启终端Windows 的字体缓存有时候懒注销一次最保险。6.3 Docker 与 WSL 集成的典型故障Docker Desktop 的 WSL 2 后端会在系统里注册两个隐藏发行版一个跑 Docker 引擎一个存镜像数据。这两个发行版对你的常规操作是透明的但它们是故障高发区。最常见的坑是有人清理磁盘时用wsl -l -v看到这两个陌生发行版以为是残留顺手wsl --unregister掉结果 Docker Desktop 直接启动失败界面提示与 WSL 相关的问题。恢复方式是卸载重装 Docker Desktop或者用它的重置功能重建这两个发行版。记住一句话名字里带 docker 的发行版别动。第二个高频问题是资源不够。Docker Desktop 用的是 WSL 的虚拟机资源配额如果.wslconfig里memory给得太小或者分配的核心数太少容器启动会超时甚至直接失败。把memory调到 8G 以上、processors至少 4 个基本能解决。第三个是版本问题。如果 WSL 太老Docker Desktop 会提示不兼容wsl --update是最直接的解法。遇到改完配置还不生效的顺序永远是wsl --shutdown再启动 Docker Desktop最后才考虑重启系统。6.4 GPU 直通与 CUDA 环境的前提条件想在 WSL 里跑 GPU 训练必须搞清楚一条铁律驱动装在 Windows 侧不要在 WSL 里装 Linux 显卡驱动。具体做法是装 Windows 版的显卡驱动较新版本已经包含 WSL 支持装完在 WSL 里执行nvidia-smi如果能看到显卡型号和驱动版本说明直通成功如果报命令不存在检查是否装了 CUDA 工具包以及是否误装了 Linux 驱动。前提条件有三条必须是 WSL2不能在 WSL1 上跑Windows 版本要足够新显卡驱动版本要达到要求。满足之后WSL 里的 CUDA 版本与 Windows 侧驱动是解耦的你可以在不同发行版里装不同的 CUDA 工具包互不干扰——这也是我把深度学习环境和日常开发环境分成两个发行版的原因避免依赖互相污染。注意如果之前手贱在 WSL 里装过.run格式的 Linux 驱动一定要彻底卸载干净再装正确的方式残留的库文件会让nvidia-smi报出非常难懂的动态库错误。7. 高频命令速查表与故障排查链路前面讲了原理和坑这里给一份可以直接贴在便签上的速查表以及三类高频故障的排查顺序。7.1 命令速查表在 PowerShell 或 CMD 里执行Windows 侧命令作用wsl --install安装 WSL 及默认发行版wsl --install -d 名称安装指定发行版wsl -l -v列出已装发行版及状态wsl -l -o列出可在线安装的发行版wsl --set-default-version 2设默认版本为 WSL2wsl --set-default 名称设默认启动的发行版wsl --set-version 名称 2把已有发行版升到 WSL2wsl --update更新 WSL 本体wsl --status查看当前状态与默认配置wsl --version查看 WSL、内核、WSLg 版本wsl -t 名称终止指定发行版wsl --shutdown关闭整个 WSL 虚拟机wsl --export 名称 路径.tar导出发行版为备份wsl --import 名称 目录 路径.tar从备份导入发行版wsl --unregister 名称注销并删除发行版危险wsl -d 名称 -u 用户以指定用户进入指定发行版wsl -d 名称 --cd ~ -- 命令在指定目录执行命令wslpath -w / -u两套路径互转发行版内部常用Linux 侧命令作用sudo adduser 用户创建普通用户sudo usermod -aG sudo 用户加入 sudo 组systemctl is-system-running检查 systemd 是否可用cat /etc/resolv.conf查看 DNS 配置ip addr show eth0查看本机 IPdf -h/du -sh *磁盘占用排查docker system prune -a清理 Docker 垃圾7.2 三类高频报错的排查顺序第一类WSL 起不来或发行版无响应。按这个顺序查wsl -l -v看状态是不是Stopped卡死wsl --shutdown强制断电wsl --update排除版本问题再不行检查 Windows 的虚拟机平台和适用于 Linux 的 Windows 子系统两个可选功能有没有被关掉系统更新后偶尔会被重置。第二类VS Code 或远程工具连不上 WSL。这类无法连接到远程计算机的提示九成不是网络问题。先确认发行版在跑再确认 VS Code 是在 WSL 终端里用code .启动的而不是手动连的然后检查\\wsl.localhost在资源管理器里能不能访问访问不了说明文件服务层有问题wsl --shutdown重启通常能解决最后再考虑扩展版本不匹配重装 Remote - WSL 扩展。第三类网络或端口访问异常。Windows 访问 WSL 里的服务默认靠localhostForwarding转发所以localhost:3000一般直接用反过来 WSL 访问 Windows 上的服务用/etc/resolv.conf里的 nameserver 地址或者直接开 mirrored 网络模式让两侧共享网络栈。如果端口映射时好时坏wsl --shutdown重来是最快的验证手段。我自己踩过最久的一次坑是折腾了两小时网络配置最后发现根因是 Windows 侧的一个安全软件拦了虚拟网卡。这个教训是当所有 WSL 侧的命令都正常、但网络就是不通时把排查范围往 Windows 侧扩一扩别一门心思在 Linux 里翻日志。另外补一个跨工具链的小经验有些 Windows 原生软件比如 MATLAB的配置里没法直接指向 WSL 里的解释器因为两者进程模型不同。变通做法是在 Windows 侧用命令行调用wsl python3 xxx.py把 WSL 当成一个可执行的外部命令来用虽然绕但比强行改配置可靠。