为什么把WSL2降级WSL1&mac迁移windows小记

前言

时隔两年还是换回了windows，本文可以算是上次文章的继承了，详情见之前发的文章
现已使用过的设备

• 联想y410p(入门笔记本)

• macbookair 2016

• AMD R5 1400, GTX 1060,8G,1T机械

• XPS 15,4K, i7 7700HQ, 16G, GTX 1050, 512SSD

• E5-2620V3,32g ecc ddr4,8t,NAS

• 技嘉 AERO 15 4K,i7 9750H,16G,512SSD(+1T SSD)

• macbook pro 16, i9, 16G, 1T, 5500m

• i3-10105f,256ssd+2tssd,16G DDR4,RTX3060(游戏机)

• surface go2 (真笔记本)

• 华硕灵耀双屏pro i9 12900h,32g ddr5,1t ssd,rtx3050ti,2.8k*2(现用主力机)

tips: 目前用的设备，给我的感觉很惊艳

为什么要换掉mac呢？

并不是因为生态不好，而是16g的内存已经支持不了我了，日常打开网页+IDE开始转圈圈，不想换主板，新款32g的话有点贵，这两年的macbook pro并没有太大更新(生态+外观+系统),然而最近翻了一下windows的笔记本,发现并没有太多能让我感觉眼前一亮的,总体来说常规向的windows轻薄本在开发效率上并没有mac用的那么爽，直到我刷到了目前的这块设备，在买之前一直在想这款副屏有什么用。
当然,macbook pro的散热问题也是一个大坑,身边小伙伴用的18款i7 macbook pro经常降频0.9ghz 根本无法使用 转轴已经被烤黄了,我的macbook 并没有出现降频问题,不过i9的cpu经常5秒真男人,macbook的键盘手感也是值得吐槽的一个点,用了这款(华硕灵耀)自带的键盘才发现手感差别太大了,我已经爱上了这款笔记本键盘了

环境替换

众所周知，买MacBook就是为了买unix环境+常用的软件(adobe系列、微信、qq等)，针对前端开发来说，前几年node环境C模块编译标准不一致，导致很多C模块都需要unix环境才能编译成功，这几年已经好了很多了，不过我还是不喜欢windows的命令行和powershell，我更加喜欢用linux来编译，但是选择了windows又怎么做到这一步呢？可以有以下几种选择方案

• 虚拟机

• DOCKER

• WSL

使用虚拟机会导致你的开发与windows分离,docker适合部署验证并不适合日常开发,于是选择就只有一个了WSL

WSL

这次换macos的原因也是因为 WSL把我恶心到了，实名diss，WSL1和WSL2。

WSL1

WSL1在使用了一年多，整体都挺不错的 尤其是跟win10本身的融合 无论是做web开发 还是当做 study Ubuntu 都是一个不错的选择，但是，在用到docker的时候和一些网络命令的时候 基本上要做权衡和舍弃了。 WSL1本身不支持docker，网上的教程我都翻了个遍，apt-get http://docker.io也是不行的，所以只能是 连接到远程的docker-daemon，那么 你这个时候的选择只有

1. 装个vm开个虚拟机装个ubuntu，启动docker-daemon，win10再连接过去

2. 本地开启hyper-v，实现docker-windows 3. 迁移WSL2

两种方案我都试过，先说说第二种。

本地开启hyper-v是支持性最好也是最完美的，但是,hyper-v跟夜神模拟器等安卓模拟器根本不兼容（运行直接蓝屏），跟vm也不兼容（目前vm新版本特性好像可以共存，未试过）这里带来的后果就是，我不能利用vm跑黑苹果，我也不能用安卓模拟器了，当时的项目需要我去模拟安卓体验..不得不说用usb连接手机调试的效率太低了。

当然..我能够忍受不跑安卓模拟器和黑苹果，于是我升级到了WSL2

WSL2
WSL2的体验不错，性能也ok，磁盘性能在ssd的面前也是可以应付日常的开发。但是随后问题就来了。 首当其冲的当然是file watch问题，众所周知 前端开发目前都会用到webpack或gulp.watch，但是这两个watch功能在wsl2并不适用，当你修改了一个文件后，并不会出发watch事件，当然也有hack办法，webpack通过配置poll可以实现监听变动。
其二是网络问题..WSL2不支持直接的外部访问，需要通过win10转发一层..这就很麻烦了，关键点在于每次重启后WSL2其ip会变，所以win10的proxy地址还不一样，虽然有脚本可以实现自动获取wsl2内部ip 写入hosts 这样win10 只需要别名代理就行了。。不过这个脚本不太好用，我开发的时候hosts文件权限过段时间会莫名奇妙变动，导致我自己都没办法编辑hosts。

network -> win10 port proxy -> wsl2

本以为上面的问题两年过去了，该解决了吧...结果并没有 反而还发现了新的问题。

WSL1 VS WSL2

官网已经写的非常清楚了，为了追新(完整linux内核)，我选择了WSL2，随后问题来了。

WSL2 file

WSL2的io性能比WSL1的io性能提升很大，但前提是 你的文件必须在WSL2系统内，什么意思呢？
WLS2的c盘挂载在/mnt/c 如果你的文件在windows本身(也就是挂载磁盘内),你的io性能会比WSL1还低(实测 三星SSD)

所以你需要把你的project file移动到 WSL2的文件系统内部,比如/home/xxx/,然后在windows环境用wsl$协议(内部为p9协议)打开此文件,这样你就能享受到飞一般的io性能了，但是，如果你使用IDE比如webstorm或者vscode(非remote wsl) 你就会有一个很大的问题

ln -s 软链接在windows环境失效

相关知识链接因无法过审可自行查找

在前端开发中,npm link是一种很常见的行为,npm link 底层会创建一个软连接，用了pnpm或者monorepo也是一种主流行为，这个时候你如果用上述的工具开发将是噩梦,wsl$协议并不支持软连接,在windows上的表现并不是一个快捷方式而是一个文件,这会导致你的webstorm没办法识别到链接的文件夹，如果你的库正好是个ts的types,则会导致你的整个项目不可编译,这个时候你有几种选择

• linux开启smb,打开smb文件夹

• mount(下文大坑)

• vs code remote wsl

• webstorm Gateway

• 直接打开/mnt/c

原本以为mount可以代替软链接，甚至有想过写个命令行来替换当前node_modules下的所有软链接，使用了mount是可以正常运行的,不过webstorm的索引会占用,导致你umount的时候需要先退出webstorm,并且这个问题在node_modules组件嵌套的时候出现需要重新运行npm run serve(以vue-cli为例),导致你写的一些方法在不重新执行编译命令并不会生效，但是文件的确有变动。另一个是 在windows下某些某些node_modules/.bin/ 是一个软连接，每次这样变动的开发成本太大了。

vs code remote

非常完美的解决了这个问题,不过我并不经常用vs code 如果你是vs code用户应该会非常开心

webstorm Gateway

问了一下群里的老哥,老哥的原话是

重度使用jetbrains Gateway开发一周总结一下，给有这个打算的小伙伴做个参考
1、后端延迟稳定性不够，变化范围较大，10～400ms浮动
2、编辑代码的时候有延迟情况，特别是输入中文的时候更明显，这个问题可能是server端CPU问题，我用机房服务器作为server端有改善
3、在mac下会出现不定期的自动重启，锁屏后无法恢复代码编辑模式需要重启gateway，有时候出现无法加载工程（较少）
4、Linux（ubuntu22.04）启动gateway闪退，无法进入界面。
5、安装插件有假死情况出现，需要重启
所以想真正的依赖gateway估计还要一段时间：）

不过远程开发怎么看都有点dirty,如果是这样我为什么不选择开一个hyper-v虚拟机呢？

直接打开/mnt/c

别看了，没办法触发文件ionotify事件,导致你的watch根本没办法监听到,并且io性能连WSL1都不如,webstorm索引在我的笔记本上要卡3分钟(中型项目),npm run serve需要2min

光这一点已经判了WSL2死刑,当然WSL2还支持CUDA，如果你不是前端开发请忽略我的这句抱怨。当然WSL2还有其他的坑，比如网络转发问题(preview版本可以直接开一个虚拟网桥来解决ip分配问题)

WSL1

于是选择回退到了WSL1，WSL1之前也是我用windows笔记本以来的开发主力，经历了大大小小的前端项目，基本上没有太多坑，除了docker外，不过这次已经放平心态选择使用docker-windows server，并且hyper-v的最新版本已经兼容vm了，这对我来说也是一个好消息。

WSL1开启软连接

Symlinks in Windows 10!
windows 10在16年就支持了软连接，只需要打开windows10的开发者模式，即可解决上述问题。

WSL1 npm link 提示文件权限不够

基本上你用sudo npm link 也是没办法解决问题的，问题的产生来源于webstorm的索引锁定了node_modules files，解决方案只需要关闭webstorm,npm link后再打开即可，其他的不影响使用，讲真方案都比mount要好用。

WSL1的io

WSL1的io并没有想象中的那么差,虽然比不上原生的io,不过介于我用的是SSD,磁盘速度是很快的,同等项目(8000+ module file)编译只需要1min08sec,跟我在macbook上启动的时间差不多,大概慢了15s左右,WSL2原生则是45s左右比macbook还快一些，机器配置不同也没办法对比，不过总的来说这个时间我是能够接受的,毕竟同事的windows台式(非wsl)编译时间也是跟我差不多

WSL之git相关的坑

我个人习惯在windows上用sourcetree来处理分支合并和提交的事情,但是WSL上还是会安装git,并且由于WSL会更改文件的filemode,windows会更改file的换行符，所以需要屏蔽git的两个config,否则你的git workspace中的文件会永远不会消失
git全局设置下述配置,已存在的git仓库从mac迁移过来的时候可能会设置filemode=true,这个时候只需要单独针对某些仓库进行配置就行

core.filemode=false
core.whitespace=false
core.autocrlf=false
core.safecrlf=true

WSL之husky lint-staged

在git提交代码的时候，主流做法是加hook进行文件校验,如果你是在windows上使用sourcetree进行提交的时候会出现一堆乱码,这个时候你需要把windows系统的区域配置打开utf8版本

设置了utf8版本 可能会导致某些软件无法使用 比如“图吧工具箱”

设置完这个后还不能正常使用,提交的时候会爆当前命令不存在,这是因为你用的WSL编译出来的是shell脚本,并不是cmd形式,你可以选择

• 用windows重新编译

• 安装对应的命令至全局

• hook使用对应的npm命令

因为git提交的基本上都是一些校验类型的,我选择直接安装对应的库至全局来解决这个问题

WSL中的换行问题

某些shell脚本可能出现尾换行导致没办法正常执行 比如

#!/bin/sh
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
. "$(dirname "$0")/_/husky.sh"

./node_modules/.bin/commitlint --edit "$1"

这个时候你只需要打开此文件,把换行符改成LF然后保存文件即可

WSL权限问题

遇事不决先设置chmod -R 777 * 可以解决某些奇怪的问题

Mac2Win数据迁移

这部分没啥好说的...由于良好的工作习惯,我的所有文件都归属在一个文件夹内,只需要整理一个zip压缩包即可,当然由于node_modules黑洞,压缩70G的文件大概在2小时左右,压缩后无缝迁移即可,迁移方式首选外置硬盘，其次本地是开个http服务 download，最后是NAS，别想着网盘迁移了。

Mac2Win软件代替

由于并没有用到什么mac专属软件，mac上常用的软件windows上基本都有，这里列出一些常用软件仅供参考

• vscode （文本编辑器）

• webstorm（大型沉浸式大脑消耗工具）

• adobe系列

• apifox（接口调试）

• wiztree（强烈推荐，大文件查找工具）

• utools（强烈推荐，代替mac聚焦搜索，支持插件，体验与mac聚焦无太大差别）

• 网易邮箱大师（代替win本身邮件管理）

• bandizip(无广告轻量级解压缩工具）

• sourcetree(git gui管理工具）

• honeyview（图片浏览器，虽然做不到mac的空格预览，但也比自带的好用）

• potplayer（视频播放器）

当然常见的工具基本上win都用，做不到系统的融合但也能整个七七八八，整体下来效果也不错

结尾

一个好的系统还需要有一个好的机器，如果无强需求要换掉mac可以再观望观望等等，为什么这次我选择出掉mac还是因为被手上这台机器种草了，具体的等下篇评测吧！

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～