一、写在前面的话
在解决了 WSL 的网络问题后，我又遇到了一个很实际的问题：提交代码的时候，到底是在 Windows 下用 Git，还是在 WSL 里用 Git 更合适？
其实我平时大多数时间都是直接在 WSL 里搞的。但有一次我在 WSL 里对挂载的 E 盘（/mnt/e/...）跑 git pull，发现终端直接卡在 Unpacking objects: 27% ... 。
查了一些资料并测试后，我理了这里面的逻辑，顺便也把 Windows 和 WSL 双环境下的 SSH 密钥配置问题梳理了一下。
不过说实话，我为了图方便都是跨系统传文件，大部分时候速度都是能接受的。
更新：纯wsl真的快很多很多！！！
二、为什么在 WSL 里操作 E 盘的 Git 会很慢？
因为跨文件系统操作的性能损耗太大了。
假设我的代码仓库放在 Windows 的 E:\NCS\Project\SpecSure。当我在 WSL 里通过 /mnt/e/NCS/... 去操作它时，WSL 实际上是需要通过微软底层的一个翻译层去访问 Windows 的 NTFS 文件系统的。
平时简单修改一个代码文件可能感觉不到，但 Git 是一个对 I/O 敏感的工具。一个 git fetch 或 git pull 往往伴随着大量小文件的读写和解包计算，这一系列操作如果频繁穿梭于 Linux 和 Windows 之间，就会变得非常慢。
所以，如果代码存在 E 盘：直接在 Windows 下（用 PowerShell 或 Git Bash）跑 Git 命令，由于是纯 Windows 环境操作本地硬盘，速度会比在 WSL 里快得多。
三、双端配 SSH 密钥，会互相覆盖吗？
既然在 Windows 下跑 Git 更快，那问题来了：如果我给 Windows 也配一套 SSH 密钥，会不会把我之前在 WSL 里配好的覆盖掉？
我之前一直有这个顾虑，总觉得好像不慎覆盖过。但后面发现：在本地机器上它们是两套完全独立的文件，不会互相覆盖。
- WSL 的密钥存在：
/home/<用户名>/.ssh/（比如~/.ssh/id_ed25519） - Windows 的密钥存在：
C:\Users\<用户名>\.ssh\
那之前为什么会有被覆盖失效的错觉？
其实问题通常出在 GitHub 网站上的操作。很多时候我们在 Windows 生成了新公钥，上传到 GitHub 时，顺手就把原来那个旧的（WSL的）给删了。结果回到 WSL 发现连不上，就误以为是本地密钥冲突了。
GitHub 是支持一号多钥的。给公钥起个好分辨的名字（比如 WSL-Laptop 和 Windows-Laptop），两把都存着就行。
四、到底怎么选？
原则：尽量不要跨界操作。
WSL 开发
如果你后续需要跑 Python、Node.js 或是 Linux 部署脚本，建议把整个项目从 E 盘挪到 WSL 自己的目录里（比如 ~/Projects/SpecSure）。
事实上我现在都懒得移动哈哈哈哈
- 全程使用 WSL 的 Git 和 SSH。
- 读写速度最快，不会有奇怪的 Windows 路径兼容问题。
Windows 开发
如果你不想挪动 E 盘的代码，或者这就是个纯前端/无需 Linux 环境的项目。
- 给 Windows 单独生成一套 SSH 密钥加到 GitHub。
- 直接用 Windows 里的 Git 终端操作。
- 避免用 WSL 去访问
/mnt/e/。
