1. 开篇为什么要折腾 WSL一条让 Windows 和 Linux 共存的成熟路径如果你手头有一台装了 Windows 11 的机器又离不开 Linux 环境下的开发工具、脚本或服务那 Windows 自带的 Linux 子系统WSL全称 Windows Subsystem for Linux应该是最省心的方案。它不像虚拟机那样需要给整套系统分配大量内存和 CPU也不用担心图形界面卡顿和磁盘占用翻倍它也不是单纯在 Windows 里硬塞一个模拟器而是通过微软官方提供的兼容层 / 轻量虚拟化技术让你在一个原生 Windows 窗口里直接跑一个 Ubuntu 之类的发行版。这篇博文围绕四个核心诉求展开把 Linux 子系统装起来、让里面的服务在开机后自动跑起来、让局域网里的其他设备能访问到子系统里的服务、以及把 Windows 的磁盘目录挂载到 Linux 环境里使用。这四个点合在一起基本覆盖了我在实际项目里用 WSL 的绝大多数场景——尤其是近期很多人提到的工控机开机自启动、ollama 局域网访问、wsl 安装后勾选功能失效等问题都会在后面逐一拆解。文章会按照“安装 → 自启动 → 局域网访问 → 磁盘挂载 → 常见问题排查”的顺序来写每一步都给出可复现的操作命令和配置方法。无论你只是想在 Windows 上跑个 Linux 终端还是想用 WSL 承载一个本地 AI 模型服务这份内容都能直接抄作业。2. 安装 Linux 子系统从零到能用的完整步骤2.1 先说清 WSL1 和 WSL2 的区别选错版本会走弯路很多人第一次接触 WSL 时会被两个版本搞糊涂。WSL1 走的是系统调用翻译层把 Linux 的系统调用转换成 Windows 的调用优点是启动快、文件 IO 和 Windows 盘符无缝互通缺点是对 Linux 内核的兼容性不够完整一些依赖 Docker、ebpf、特定内核模块的软件无法运行。WSL2 则是在 Hyper-V 虚拟化平台上运行一个完整的 Linux 内核兼容性大大提升。现在的 Docker Desktop 可以直接复用 WSL2 后端ollama 这类本地模型服务也能正常运行。如果你的机器支持虚拟化BIOS 里开了 VT-x 或 AMD-V那直接上 WSL2 是标准选择如果机器太老或虚拟化被锁才需要退回 WSL1。检查虚拟化是否开启最简单的方式是打开任务管理器切到“性能”标签看 CPU 部分有没有“虚拟化已启用”。如果显示“已禁用”需要进 BIOS 开启这一步不做后面装 WSL2 会一直报错。提示WSL2 的磁盘文件默认存储在 ext4.vhdx 里访问 Windows 盘的 /mnt/c、/mnt/d 反而比 WSL1 略慢。所以如果你只想要一个 Linux 终端环境很少跑重负载服务WSL1 反而更轻快。但考虑到 Docker、AI 推理这类热门场景WSL2 是当前的主流选择。2.2 新机简化安装一行命令搞定 WSL2Windows 11 的 WSL 安装如今已经比 Win10 时代简化很多。打开 PowerShell管理员身份执行wsl --install这条命令的使命很明确把 WSL 核心组件、虚拟机平台功能、默认的 Ubuntu 发行版一次装齐。安装完成后系统会要求重启重启后进入 Ubuntu 首次配置界面设置 Linux 用户名和密码即可。如果你希望指定发行版比如想用 Debian 或 Kali可以执行wsl --list --online wsl --install -d Debian我自己的经验是第一次安装时网络很重要。wsl --install 需要从微软服务器下载组件和发行版镜像如果网络不稳定可能装到一半报错。遇到这种问题可以稍后重试或者先把 Windows 更新装上再执行安装命令。安装完成后在开始菜单里搜索 ubuntu 即可启动。常用检查命令wsl --status wsl --versionwsl --status会显示当前 WSL 版本wsl --version会显示 WSL 内部组件的详细版本号。如果默认版本不是 2可以用wsl --set-default-version 2把默认版本固定为 WSL2。2.3 历史遗留问题勾选“适用于 Linux 的 Windows 子系统”后重启就失效最近网上讨论很热烈的一个现象是在“启用或关闭 Windows 功能”里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”结果重启后勾选状态又恢复原状WSL 根本无法启用。这种情况我在几台机器上都见过。本质原因是 Windows 功能开关写入失败或者被系统策略、第三方优化工具拦截。排查思路分三步第一步确认 Windows 版本。老版本的 Windows 10 对 WSL2 的支持不完整出现功能开关回滚很正常。建议把系统更新到最新版 Windows 11。第二步使用 DISM 命令手动启用功能而不是只靠图形界面勾选。在管理员 PowerShell 里执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart然后重启。这次重启后功能状态应该能保住。如果仍然回滚说明系统镜像或策略有问题可以尝试运行系统文件检查sfc /scannow或者用 Windows 11 安装介质做一个修复升级这种方式能最大程度保留现有软件和数据。第三步第三方安全软件、系统优化工具可能把功能开关强制关闭。如果上述两步都无法解决临时卸载或退出这类工具再执行一次启用命令。2.4 装完先做三件事换源、更新、配置默认用户Ubuntu 装好后的第一件事我会把软件源换成国内镜像否则 apt 下载速度太慢。编辑源列表sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i s/archive.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list sudo apt update sudo apt upgrade -y我这里用的是阿里云镜像实际环境里也可以换成清华、腾讯、中科大源原理一致。第二件事是改默认用户。如果你装好了 WSL但每次在 Windows 终端里输入 wsl 后进入的是 root或者反过来想用 root 结果进去是普通用户都可以用这样一条命令切换默认用户wsl --manage Ubuntu --set-default-user 用户名如果命令提示不支持也可以直接进入 WSL 后执行echo 用户名 /etc/wsl.conf然后在 [user] 段落里加上 default用户名。第三件事是确认 systemd 是否可用。新版 WSL20.67.6 及以上默认支持 systemd这对服务自启动的配置至关重要。检查方式ps -p 1 -o comm如果输出的是 systemd说明一切正常。如果输出的是 init说明 systemd 未启用需要在 /etc/wsl.conf 里添加[boot] systemdtrue然后在 Windows PowerShell 里执行 wsl --shutdown重新进入 WSL 让配置生效。3. 服务自启动开机后让 Linux 里的服务自动跑起来3.1 理解 WSL 的启动机制为什么服务不会自动启动WSL 和传统虚拟机不同它的生命周期和 Windows 登录会话绑定。默认情况下只有在你打开一个 WSL 终端窗口时对应的 Linux 发行版才会启动关闭所有 WSL 窗口后系统会在几秒内自动回收这个发行版的进程。这意味着你无法指望像 systemctl enable 那样在 Windows 开机时就自动拉起 WSL 里的服务。要实现服务自启动正确的思路是在 Windows 登录后主动执行 wsl 命令让 WSL 实例启动进入 Linux 后由 systemd 接管并启动所需服务。这也是工控机上电自启动的常规配置方式——Windows 开机后通过任务计划程序触发一条命令WSL 里的服务自然就跟起来了。这里有一个关键细节wsl.exe 命令在首次启动发行版时会返回一个交互式 shell 的退出码但服务进程会在 WSL 关闭后继续运行一段时间。如果所有 WSL 窗口都关闭服务会随实例回收而终止。因此为了让服务常驻需要让 WSL 实例在后台保持运行或者使用wsl -d Ubuntu --exec的方式让系统认为有进程在占用。3.2 首选方案用 Windows 任务计划程序实现开机自启动我在实际项目里最常用、最稳的方案就是任务计划程序。打开“任务计划程序”右侧点击“创建任务”在“常规”标签里填写任务名称比如 WSL-AutoStart勾选“使用最高权限运行”并选择“不管用户是否登录都要运行”。在“触发器”标签里新建触发器选择“启动时”或“登录时”。如果你希望服务在用户输入密码进入桌面后启动选“登录时”如果希望更早启动选“启动时”。工控机场景通常选“登录时”即可因为需要桌面环境配合网络初始化。在“操作”标签里新建操作程序填写wsl.exe参数填写-d Ubuntu -u root --exec /bin/bash -c systemctl start your-service-name如果你是希望 WSL 实例常驻不退出可以改成启动一个 keep-alive 命令比如-d Ubuntu -u root --exec /bin/bash -c tail -f /dev/null任务计划里的wsl.exe默认会弹出控制台窗口虽然不影响功能但看着有点碍眼。解决方法是在程序路径里使用 conhost 的隐藏参数或者把 wsl.exe 包一层写成cmd /c start /min wsl.exe -d Ubuntu -u root --exec /bin/bash -c systemctl start your-service-name这样窗口会在最小化状态运行桌面不会显得杂乱。3.3 备用方案开机启动文件夹和组策略如果你的使用场景不需要管理员权限或者只是想在用户登录后快速启动某个脚本可以把一条 wsl 命令的快捷方式放进“启动”文件夹。最简单的方法是写一个 .bat 文件内容echo off wsl.exe -d Ubuntu -u root --exec /bin/bash -c /home/user/startup.sh然后把这个 .bat 文件放到运行框输入shell:startup打开的启动文件夹里。这种方式的好处是配置简单不需要创建任务计划缺点是必须等用户登录后才执行且如果 WSL 启动失败没有重试机制不如任务计划程序可靠。另一个思路是用组策略的脚本配置在gpedit.msc里找到“计算机配置 → Windows 设置 → 脚本(启动/关机)”添加一个启动脚本内容同样是 wsl 命令。这种方案适合企业环境下统一分发配置但对普通用户来说配置门槛偏高不如任务计划直接。3.4 在 WSL 内部配置 systemd 服务让自启动更优雅既然 WSL 支持 systemd那我们应该把服务定义成标准的 systemd 单元而不是在启动命令里手写一堆 shell 脚本。以 ollama 为例创建一个服务文件sudo nano /etc/systemd/system/ollama.service内容大致是[Unit] DescriptionOllama Local AI Service Afternetwork-online.target Wantsnetwork-online.target [Service] Userroot ExecStart/usr/local/bin/ollama serve Restartalways RestartSec3 [Install] WantedBymulti-user.target保存后执行sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama这样只要 WSL 实例被拉起systemd 就会自动启动 ollama。配合前面创建的任务计划在 Windows 登录时拉一次 WSL 实例ollama 就一直在后台跑着。提示WSL2 的 systemd 并不是完整照搬一台物理 Linux 上的 systemd有些依赖硬件设备、电源管理的单元不可用。如果某个服务无法启动先看 journalctl -u 服务名 -n 50 的输出多数问题是缺少硬件设备或网络等待时间不足。4. 局域网访问让其他设备连上你 WSL 里的服务4.1 先看现象为什么 localhost 能访问局域网却不行这是一个高频问题。WSL2 的网络模式和传统虚拟机不同它并不是直接从路由器获取一个局域网 IP而是通过 Windows 的虚拟交换机做 NAT。简单来说WSL2 里的 IP 是 NAT 网络内的地址Windows 主机的 localhost 转发只对本地回环有效。举个例子你在 WSL 里启动了 ollama监听 0.0.0.0:11434。在 Windows 本机的浏览器里访问 http://localhost:11434 可以正常响应但同一局域网内其他电脑用 http://Windows主机的IP:11434 访问却大概率连不上。原因有两层一是 WSL2 的服务没有自动映射到 Windows 主机的端口上二是 Windows 防火墙默认拦截外部入站连接。对局域网内其他设备来说WSL 里的服务进程相当于藏在一个“内网的内网”里。4.2 方案一netsh 端口转发 防火墙放行最经典的做法是用 Windows 自带的 netsh 命令做端口转发。在管理员 PowerShell 里执行netsh interface portproxy add v4tov4 listenaddress0.0.0.0 listenport11434 connectaddress127.0.0.1 connectport11434这条命令的含义很清晰让 Windows 主机监听所有网卡上的 11434 端口收到连接后转发到 127.0.0.1 的 11434 端口。由于 WSL2 和 Windows 会通过 localhost 互通所以 connectaddress 写 127.0.0.1 就能访问到 WSL 里的服务。但只有端口转发还不够Windows 防火墙默认会拦截外部对 11434 端口的访问。需要新建入站规则netsh advfirewall firewall add rule nameWSLPort11434 dirin actionallow protocolTCP localport11434如果想同时允许 UDP可以再加一条。这一步做完局域网其他设备就能通过http://Windows主机的IP:11434访问到服务了。注意管理员权限是必须的否则 netsh interface portproxy 和 netsh advfirewall 会报“请求的操作需要提升”。4.3 方案二直接把 WSL 实例放进局域网镜像网络模式netsh 方案用起来没问题但有一个明显痛点如果服务端口变化或者你想让多个服务同时暴露到局域网就要反复修改端口转发表比较繁琐。而且服务监听在 0.0.0.0 或特定 IP 上网络模式是 NAT每次重启 WSLNAT 网络的虚拟网关地址还可能变化。比较新的 Windows 11 版本WSL 2.0.0支持一种叫 mirrored 的网络模式也就是镜像网络模式。在这种模式下WSL 直接共享 Windows 主机的网络接口不再有独立 IP 和 NAT 隔离。换句话说WSL 里的服务如果监听 0.0.0.0宿主机局域网上的设备可以直接通过 Windows 主机的 IP 访问不再需要 netsh 转发。开启方式是在用户目录下创建或编辑 .wslconfig 文件[wsl2] networkingModemirrored然后执行wsl --shutdown重新进入 WSL 后查看 IPip addr show eth0如果看到地址和 Windows 主机网段一致说明镜像模式生效了。此时无需任何 netsh 转发Windows 防火墙只需要放行对应端口即可。我在测试 ollama 局域网访问时发现镜像模式对 Windows 11 22H2 以上系统支持较好但如果你用的是老版本 WSL可能没有这个选项。升级 WSL 的方法是wsl --update wsl --version4.4 让局域网访问更稳定静态映射和动态端口的处理netsh 端口转发有一个隐蔽的坑WSL2 的 NAT 网络地址在每次重启后可能变化但这不影响 127.0.0.1 的转发因为 Windows 和 WSL 之间的 localhost 互通是稳定的。所以 netsh 方案在“通用访问”层面其实还算稳妥。但如果你安装了多个发行版或者 WSL 里跑了 DockerDocker 的容器端口映射可能会产生额外的 NAT 层导致 netsh 转发时出现端口冲突。处理方式是把服务监听地址显式设置为 0.0.0.0而不是回环地址同时检查 Docker 的 -p 参数是否与 netsh 转发的端口重复。另一个稳定性的问题是动态 IP。如果你的 Windows 主机在局域网内用的是 DHCP 动态获取 IP那局域网内其他设备记下的 IP 可能在几天后失效。最简单的方案是在路由器管理界面为这台 Windows 主机绑定一个固定 DHCP 保留地址或者直接在 Windows 网卡设置里写死一个静态 IP。这样局域网访问地址就一直是同一个。对于需要让局域网设备长期访问的场景除了端口转发我还会检查服务本身的监听地址。有些服务默认只监听 127.0.0.1这在 WSL 里尤其常见。如果服务绑定在 127.0.0.1即使 netsh 转发到 127.0.0.1:端口外部设备也不可能访问到因为服务没监听在外部可达的接口上。所以排查步骤是在 WSL 里执行 ss -tlnp | grep 端口确认服务监听的是 0.0.0.0 还是 127.0.0.1。如果监听了 127.0.0.1修改服务配置为 0.0.0.0或者设置 HOST0.0.0.0 环境变量。在 Windows 本机先访问 localhost 确认服务状态。再执行 netsh 转发和防火墙放行。ollama 的情况比较特殊它默认监听 127.0.0.1:11434。要让它可被局域网访问常见做法是设置环境变量 OLLAMA_HOST0.0.0.0然后重启 ollama 服务。这个细节很多人在部署本地模型时踩过坑。5. 磁盘挂载让 Windows 目录和 Linux 环境无缝互通5.1 WSL 默认的自动挂载机制WSL 最让人舒服的一点是Windows 的所有盘符会自动挂载到 /mnt 目录下。比如 C 盘对应 /mnt/cD 盘对应 /mnt/d。你在 Linux 终端里直接 cd /mnt/d/workspace 就能操作 Windows 里的文件反过来在 Windows 资源管理器里输入 \wsl$\ 路径也能直接访问 WSL 里的文件。这个自动挂载机制由 WSL 内部的 init 进程实现不需要额外配置。但要注意/mnt/c 这类目录的读写性能相比 WSL 内部的 ext4 文件系统有明显差距。尤其是大量小文件的读写在 drvfsWSL 对 Windows 文件系统的驱动上会慢很多。如果你的项目是编译、构建这类 IO 密集任务我建议把源码放到 WSL 内部目录比如 /home/用户名/project而不是放在 /mnt/d 下。5.2 手动挂载U 盘、移动硬盘和其他磁盘分区自动挂载虽然方便但并不是所有设备都会自动出现在 /mnt 下。U 盘、移动硬盘以及一些未自动挂载的分区需要手动挂载。先插入设备然后查看设备编号。在 WSL 里执行lsblk这个命令会列出所有块设备。Windows 下的磁盘分区在 WSL 里的表现形式通常是 sda、sdb、nvme0n1 等。找到你想要挂载的分区后创建一个挂载点并挂载sudo mkdir -p /mnt/e sudo mount -t drvfs E: /mnt/e这里的 E: 是 Windows 盘符。挂载完成后在 /mnt/e 下就能看到对应的文件内容。卸载时使用sudo umount /mnt/e如果你希望开机自动挂载某个固定盘符可以在 /etc/fstab 里添加一行格式如下E: /mnt/e drvfs defaults,noatime 0 0但要注意WSL 的 fstab 不一定在每次启动时都会读取如果发现没有自动挂载检查 /etc/wsl.conf 里的 [automount] 配置。5.3 通过 /etc/wsl.conf 定制挂载行为WSL 的挂载行为可以通过 /etc/wsl.conf 自定义。这个文件是 WSL 里比较核心的配置文件之一常用配置如下[automount] enabled true root /mnt/ options metadata,umask22,fmask11 mountFsTab trueenabled是否启用自动挂载。root自动挂载的根目录默认是 /mnt/。options挂载选项。metadata 表示让 Linux 在挂载的 Windows 文件上支持 chmod 和 chownumask 和 fmask 用来控制权限。mountFsTab是否读取 /etc/fstab。如果你经常需要操作 Windows 目录下的脚本并且希望它们有可执行权限metadata 选项就很有用。如果不加这个选项WSL 会把所有 Windows 文件都当作 0777 权限这对部分需要检查执行权限的工具会造成困扰。修改完 /etc/wsl.conf 后需要执行wsl --shutdown再重新进入 WSL 才能生效。注意wsl.conf 只会影响后续启动的实例对当前运行的 WSL 没有热加载能力。5.4 反向访问从 Windows 资源管理器操作 Linux 文件磁盘挂载不只是让 Linux 访问 Windows 文件反过来也同样重要。WSL 的文件系统在 Windows 下有独立的访问入口。在资源管理器地址栏输入\\wsl.localhost\Ubuntu\home\用户名就能像访问 Windows 本地目录一样浏览 Linux 里的文件。复制、粘贴、编辑都很方便适合不熟悉命令行的人操作。对于需要频繁和 Windows 交互的目录我建议在 WSL 里创建一个符号链接比如ln -s /mnt/d/workspace ~/workspace这样在 Linux 里访问 ~/workspace 就等价于访问 D 盘的 workspace 目录路径短了很多也更直观。5.5 磁盘空间管理别再让 vhdx 无限膨胀WSL2 的镜像是一个动态扩展的 vhdx 文件默认放在C:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx。它不会自动收缩。你删除了大量文件后这个 vhdx 文件可能依然占据着曾经的最大值空间。如果你发现 C 盘空间越来越小需要手动压缩 vhdx。步骤是在 PowerShell 里执行 wsl --shutdown。打开管理员 PowerShell定位到 vhdx 所在目录。执行 diskpart。在 diskpart 里依次执行select vdisk fileC:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu...\LocalState\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit压缩过程可能需要几分钟执行完成后重新启动 WSL 即可。这个方法我在用完 Docker 构建缓存之后试过C 盘能腾出几个 GB 空间效果还是很明显的。6. 常见问题排查安装、启动、访问环节的坑和对应解法6.1 安装和启动阶段的疑难杂症错误WslRegisterDistribution failed with error0x8007019e 这个错误在旧版 WSL 上很常见通常是因为 Windows 版本太老或者没装内核更新包。解决方法是运行 wsl --update然后重试启动。错误The service cannot be started, either because it is disabled or it has no enabled devices associated with it. 这个错误和 Hyper-V 服务被禁用有关。在管理员 PowerShell 里执行Get-Service vmcompute如果状态不是 Running可以执行Set-Service vmcompute -StartupType Automatic Start-Service vmcompute再去启动 WSL。现象WSL 启动后一直转圈卡在 “Installing, this may take a few minutes...” 这通常是网络问题发行版镜像没下载完整。可以先关闭当前窗口执行 wsl --shutdown然后使用 wsl --update再重新启动发行版。现象WSL 版本明明是 2但 Docker Desktop 提示需要 WSL2 backend。 检查 Windows 功能里是否启用了“虚拟机平台”。如果没启用WSL2 无法运行。启用方式是前面提到的 DISM 命令。6.2 服务访问常见问题速查表现象可能原因解决方法本机 localhost 能访问局域网设备不能WSL2 NAT 隔离 Windows 防火墙拦截使用 netsh 端口转发并放行 Windows 防火墙入站端口局域网能访问 IP 但服务无响应服务监听在 127.0.0.1修改服务配置监听 0.0.0.0或设置 HOST0.0.0.0Windows 重启后端口转发失效netsh 本身不持久化创建任务计划程序开机时重新执行 netsh 添加命令WSL 服务自启动后偶尔没起来systemd 等待网络超时在服务单元里增加 Afternetwork-online.target 和 Wantsnetwork-online.target局域网访问时提示找不到主机Windows 主机 IP 变化在路由器上绑定 DHCP 保留地址或设置静态 IP防火墙已放行但局域网访问仍失败路由器开启了 AP 隔离或防火墙登录路由器管理页关闭 AP 隔离检查安全策略6.3 我的故障排查顺序实战心得遇到 WSL 服务访问不通的问题我一般按这个顺序排查先确认服务在 WSL 内部是否正常。进入 WSL 执行curl http://127.0.0.1:端口如果返回正常排除服务本身的问题。如果服务报错看 journalctl -u 服务名 -n 50对症处理。再确认 Windows 本机访问http://localhost:端口是否正常。不正常时说明 WSL 与 Windows 的 localhost 互通出问题。可以用wsl --shutdown后重启 WSL 试试绝大多数情况下能解决。然后检查 netsh 端口转发表是否还在。netsh interface portproxy show all可以查看所有转发规则。如果转发规则缺失重新添加。如果转发规则在但访问仍失败多半是防火墙拦截按netsh advfirewall firewall show rule name端口号检查入站规则。最后才去查路由器和其他设备层面。这个过程可以避免很多无谓的折腾尤其是当你同时配置了多个服务时按层排查是最高效的。6.4 Docker 和 WSL 结合时的额外注意点如果你在 WSL 里用了 Docker比如 Docker Desktop 开启了 WSL2 后端局域网访问容器的端口映射会多一层封装。Docker 的 -p 参数会把容器端口映射到 WSL 实例的某个 IP 上然后你需要再把这个 IP 的端口映射到 Windows 主机。这种叠加转发比较容易搞晕。我的经验是始终在 Windows 主机层面做统一的端口转发入口。例如 Docker 容器暴露 8080 端口WSL 里访问 127.0.0.1:8080 能通那么 Windows 上就建一条 80 端口到 127.0.0.1:8080 的 netsh 转发。这样局域网设备统一通过 http://Windows主机IP:80 访问不需要关心 Docker 内部网络细节。另外Docker Desktop 默认使用的 WSL 发行版是 docker-desktop 这个隐藏实例它的 IP 地址和普通 Ubuntu 实例不同。如果你在 Ubuntu 里跑 ollama又想通过 Docker 跑另一个服务并互相访问需要让两个服务都监听在各自实例的 0.0.0.0 上并确保网络互通。最简单的方式是使用镜像网络模式把所有 WSL 实例和 Windows 放在同一网络平面省去很多桥接的烦恼。7. 一些值得长期保留的经验再分享一个我实际配置过程中体会最深的点WSL 本身就是一套“在 Windows 上跑 Linux 服务”的完整方案但你一定要把它当一台真正独立的 Linux 服务器对待。备份重要数据、定期更新 apt 包、控制 vhdx 体积、限制日志文件大小这些基本功一样都不能少。如果你像我一样主要是为了跑本地 AI 模型ollama或者内部知识库工具那我强烈建议在 WSL 里配合 systemd 把这些服务都做成标准单元再统一由一个 Windows 任务计划触发。这样即使在无人值守的工控机场合Windows 开机后 30 秒内服务就已经处于可用状态省去了手动打开终端一个个 start 的麻烦。最后再补充一个日常使用的小技巧在 Windows 11 的终端里WSL 可以和 PowerShell 并排使用直接用命令wsl就能进入默认发行版。如果你希望在某些项目里固定使用某个发行版可以用wsl -d Debian这样指定。日常操作 Linux 文件和启动服务都可以在 Windows 终端完成不必单独打开 Ubuntu 窗口。这个小习惯能让你减少上下文切换使用体验会顺滑很多。