使用 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 上也可以找到由社区配置好的版本，不过这些版本并不是由官方维护的。