使用 WSL2 开发环境的体验

使用 WSL2 作为实际项目中的开发环境有一段时间了，讲述一下我体验到的一些 WSL2 的优缺点。

我在 WSL 上使用的发行版为 Debian 和 Ubuntu。

优点#

安装便捷#

WSL 的安装非常的方便，由官方维护且适用于 WSL 的发行版可以直接通过 Microsoft Store 获取。安装完成后，会添加在开始菜单中，打开后设置好用户名与密码即可开始使用。

与 Windows 的整合#

WSL 会直接使用 Windows 上的网络，如我们在 WSL 上运行一个项目，它监听了 localhost:8080 这个地址和端口号，我们可以直接在 Windows 访问这个地址来预览该项目。

WSL 可以直接访问 Windows 下的目录，反之也可以。

在使用 Linux 的环境的同时还能享受到 Windows 软件生态#

这个应该不需要我多说了。

缺点#

内存与存储空间占用大#

WSL2 本质上其实是一个虚拟机，需要额外的 CPU、内存与存储空间的开销，这是无法避免的。

即使我用 WSL 只是用于运行项目，只使用了命令行并没有使用到图形界面，但有的时候内存使用量会非常高。

只在使用命令行的情况下，目前遇到 WSL 最高内存使用量是在 6G 多一点这样，加上在 Windows 这边运行的软件，差不多要把我的 16G 内存给吃满了。

通常为了方便，我会直接使用项目中的配置进行 E2E 测试，这样就无法避免的需要在 WSL 中开启 Chrome 并使用。虽然 Windows 这边也已经开启了 Chrome，但是它们无法共用，只能眼睁睁地看着电脑运行着两个 Chrome。 （虽然现在的电脑上同时有数个 chromium 在运行已经是常态了）

与 Windows 整合性可能也带来一些麻烦#

例如我想使用 n 来管理 Node.js 的版本，n 在安装时会检测是否已经安装过 Node.js。

如果在 Windows 上已经安装了 Node.js，它会在安装时提示我们已经在 Windows 的目录下安装过 Node.js 并停止安装 😅。

图形界面缩放问题#

例如我的显示设置是使用 150% 缩放比例，当我 WSL 运行 Chrome 的时候，发现 Chrome 的 UI 控件都非常小。很明显，这是使用了 100% 的缩放比例而而非系统设置中的 150%。

在高分辨率的屏幕的情况下，100% 的缩放比例是大部分人无法接受的。

根据这条 issue 来看，似乎目前只支持 100% 的倍数作为缩放比例。虽然可以通过一些配置可以支持像是 150% 这样的比例，但显然在其他人的反馈中，它可能会不起作用或表现得并不是很好。

Hyper-V 的兼容问题#

这一点可看我的另一篇文章。

由官方支持并适用于 WSL 的发行版少#

目前由官方支持并适用于 WSL 的发行版并不多，在 Linux 中的众多发行版中只是冰山一角。

虽然官方也提供了方案可供我们在 WSL 上选择自己的偏好的发行版，但相对来说比较的麻烦。我们也可以在 GitHub 上也可以找到由社区配置好的版本，不过这些版本并不是由官方维护的。