Windows wsl 和 前端

在 Windows 里写代码，在 WSL（Linux）里跑服务，之所以能顺畅通信，核心原理用一句话概括就是：微软在底层把这两套系统家的“大门”和“网络”偷偷打通了。

我们可以把 Windows 想象成“客厅”，把 WSL 想象成“地下室”。这两个房间虽然是隔开的，但有一条专用通道相连。

---

原理篇：它们是怎么聊上天的？

1. 网络层面的打通：“本地回环”共享

在以前的老技术（比如虚拟机 VMware）里，虚拟机和宿主机会被分配两个不同的 IP 地址，比如客厅是 192.168.1.10，地下室是 192.168.1.11，互相访问要写长长的 IP 址。

而在 WSL2 中，微软做了一个超级贴心的设计：网络端口转发映射。
当你在 WSL（地下室）里启动一个服务，并让它监听 localhost:8080 或 127.0.0.1:8080 时，Windows 系统会立刻知道这件事，并自动把 Windows 客厅里的 localhost:8080 请求，直接穿透转发到地下室。

• 结果就是：你感觉不到它们是两台机器。你在 Windows 的浏览器里敲 http://localhost:8080，就能直接看到 WSL 里跑的网页或服务。

2. 文件层面的打通：“共享挂载”协议

除了网络，连文件系统也是打通的。

• 在 Windows 看 WSL：Windows 可以通过网络驱动器协议（Plan 9）直接读取 Linux 里的文件。你在 Windows 的资源管理器里输入 \\wsl$，就能像浏览 C 盘 D 盘一样浏览地下室里的文件。
• 在 WSL 看 Windows：WSL 把 Windows 的 C 盘、D 盘直接挂载到了 /mnt/c、/mnt/d。这就意味着，在 WSL 的终端里，可以直接读取修改你在 Windows 里存的代码。

3. 进程层面的打通（特定软件的魔法）

像 VS Code 这种现代软件，更进一步。它设计了 “Remote - WSL” 扩展插件：

• VS Code 在 Windows 的客厅里画 UI 界面。
• 它悄悄派一个小弟（Server 端）钻进 WSL 地下室里。
• Windows 里的界面通过内部通道（RPC/Socket）向地下室的小弟发号施令，读取文件、执行终端命令。
• 因此，你在 Windows 里的 VS Code 敲命令，实际上是在控制 Linux。

---

实践篇：需要怎么配置才能跑起来？

大部分情况下，你什么都不用额外配置，因为微软默认已经做得很好了。但为了确保稳定运行，通常只需要注意以下几点：

1. 确保 WSL 侧的服务绑定正确的 IP (0.0.0.0)

很多开发者会遇到：“明明在 WSL 里服务启动成功了，为什么在 Windows 浏览器输入 localhost 却打不开？”

• 原因：有些开发框架（比如 Vue, React 的某些版本，或者 Flask）出于安全考虑，默认只会监听 127.0.0.1，这意味着它只允许“地下室内部”的人访问。
• 配置方法：在启动 WSL 里的服务时，强行让它监听 所有网络接口 (0.0.0.0)。
• 比如 Node.js 启动：通常是在启动脚本里加 --host 0.0.0.0
• 比如 Python Flask：app.run(host='0.0.0.0')

2. 使用 VS Code 作为桥梁（最推荐的开发方式）

如果你的“前端在 Windows，服务在 WSL”，最舒服的配置是：

1. 在 Windows 里安装 VS Code。
2. 在 VS Code 的扩展商店安装 “WSL” 插件（由 Microsoft 提供）。
3. 打开 WSL 的终端，进入你的代码目录，输入命令 code .。
4. VS Code 会在 Windows 弹出界面，但在左下角会显示绿色的 “WSL: Ubuntu”，此时，你的编辑器已经自动打通了两个世界。你可以直接在编辑器自带的终端里跑 Linux 服务了。

3. 文件存放的黄金法则

虽然双方能互相读文件，但跨系统读写文件是有性能损耗的（跨系统 I/O 比较慢）。

• 错误配置：把代码存在 Windows 的 D 盘 (D:\project)，然后在 WSL 里通过 /mnt/d/project 跑编译打包，速度会慢到让人怀疑人生。
• 正确配置：把前端和后端的源码直接放在 WSL 的家目录下（比如 ~/my_project）。然后用上面提到的 VS Code (通过 WSL 插件) 去编辑它。这样，文件读写完全在 Linux 内部极速完成，只有最终运行的界面通过网络传给 Windows。