机缘巧合周末搞了台 Windows 台式机，体验了一波发现响应速度都超级快，不管是浏览器还是办公套件，于是萌生了用 Windows 做开发机的念头

但是我现在没搞明白 WSL 存在的意义，我举一个场景比如 nodejs 开发

宿主机的 sublime 或者 vscode 或者 Git GUI 如果想正常使用，得在宿主机装一套 sshd nodejs eslint 这类工具，好像就没 WSL 什么事了

如果说有的程序需要 Linux 环境，ok 我用 vscode remote wsl 插件连接到 WSL ，使用 WSL 里面的开发环境，但是 WSL 挂载 git 的时候，文件权限全部 777 ，也是很影响使用

文件权限问题，实在不行我把代码放在 WSL 内部，也能忍，但是和宿主机文件传输好 jb 慢啊，5 分钟传不完 200M 的碎文件

传输慢也就还能忍，大不了全部放在 WSL 里面，但是我的工作区是用 syncthing 同步的，WSL 安装完发现 systemctl 不能用

systemctl 不能用我也认了，大不了每次手动启动 syncthing ，但是启动完发现 WSL 的端口只能在 localhost 访问，而 NAS 连不上，或者说需要额外配置才能连上

可如果我在宿主机同步 syncthing ，就又会遇到 git 文件权限 777 问题，完美循环了

所以想请教下各位，Windows 下舒服的开发姿势是什么样的，WSL 一把梭，还是宿主机一把梭，还是有什么奇巧淫技

我在公司是通过 vscode 的 sftp 把代码同步到开发服务器，或者用 remote-ssh 直接在服务器上改，本地只做一个编辑器使用。wsl 的话，我用了几款，都遇到过奇奇怪怪的问题，个人觉得 ubuntu18 相对好一点。

前端就用 windows 开发，用什么 wsl 。。。

能宿主机就宿主机，实在不能宿主机，比如我编译 k8s 源码，就用 wsl ，觉得 wsl 也不好用，就 linux 虚拟机，

不要对 wsl 期望太高，把它看成一个轻量级的虚拟机用。

在开启了 WSL 的 windows 上装 docker, docker 里启动 mysql postgresql redis, 既可以享受最新的 linux 软件镜像，主体在 windows 上开发。我就是这么用的

装纯 linux 的话 ，国产 微信 ，QQ ，GPU 闭源驱动又是大问题

WSL 跑服务遇到更新重启，会出现怪异的问题，导致重装。（环境变量全部丢失，甚至包含 userprofile 丢失，系统基本无救）

考虑到 win10 尿性，最好别用了……

目前就是 VMplayer 跑个 guest 主机，vscode remote debug

前端有什么是 windows 下搞不定的吗非得要用 linux?

直接用 Windows （关闭 wsl ）不就行了？

感谢各位答疑，你们还真是整齐，评价一边倒，看来结论就是 WSL 对开发没啥卵用，最多在里面用用 Linux 小工具集

wsl 的存储和网络都有问题，，，我还是倾向与这玩意是个玩具。

我是用命令行比较多, wsl 对我来说是使用 windows 的最大动力.

如果你习惯使用 windows 的工具链,那 wsl 对你来说是没什么用. 我很多工作的工具都是 Linux Only 的.

wsl 挂载 git 的时候权限问题,我没遇到过这个问题. 猜测可能是 git 从 windows 下拉的 repo, 我个人是 git 拉到 wsl 中运行,当然也有拉到 windows 目录下的,使用也没问题.

至于文件同步问题,我个人这边是没有进行文件同步的,即便是 windows 目录下 /mnt/c/Users/pc/Developer/test 这种文件,我用 git 的时候也在 wsl 下 git pull 之类的, windows 下没有进行过 git 操作.

我觉得 wsl 简直太香了.

当然 wsl 也不是没有问题,比如上周,我打算使用 wsl 下的 golang 进行开发, goland 直接卡住了,查询了一圈 issue 目前这个问题无解, wsl2 下暂时就这么慢, wsl1 还行.

你没用到的东西 Windows 上都有的话完全没必要用 wsl…

我觉得 wsl 挺好用，本人 c++，golang 开发，linux 运维，wsl 提供了一个和 linux 一样的 unix 环境，能很方便的和 windows 共享文件。vscode 能高效地集成 wsl 开发环境，体验比 ssh 好一个数量级。并且能很方便切换不同的 linux 发行版，系统版本。
有了 wsl ，基本就不用 linux 开发机了。

用 WSL1 ，网络没问题；
项目文件放在 WSL 用户的 home 目录下；
用 vscode 搭配 remote-wsl 做开发；
需要 docker 时，不用 WSL2 版本，用 Hyper-V 版本，配置 DOCKER_HOST 让 WSL1 能连接 docker daemon ，用 mount --bind 把 mnt 下的目录映射到根目录，使其跟 Hyper-V 中的目录一致，以便正常挂载 Volume 。

用这玩意需要一定的 Linux 知识，并非开箱即用……

systemd 不能跑其实很莫名其妙，只要注释掉 systemd 里 getpid_cached() != 1就能执行。

git config core.filemode false
比较时忽略文件属性，也许有用？

＃2 有些时候别人的项目只能用 node 14, 你电脑上是最新的 node 16. 这时候用 wsl+docker 就很合适

直接用 Multipass 不香吗

有用的，但是还有额外两个问题，所以我最终还是没改成 false

1 个是 git pull 默认的配置文件（ git 仓库的配置）还是 filemode true
2 就是 filemode 偶尔还是会用到，比如代码仓库有几个脚本，想改成 +x 权限

拿 WSL 写前端就跟拿 WINE 跑 mingw 写 C 一样绕远路

我也用 nodejs 写后端哈，所以还是有一些需求的，比如配置文件在 WSL 下就可以沿用 / 路径风格，再就是 Windows 下开发，部署在 Linux 总归还是有点慌的

你说的这个没错的，我是在宿主机克隆的仓库，如果 WSL 一把梭就没啥问题，WSL 一把梭主要问题是文件拷贝太慢，还有端口映射麻烦一些

提醒下，如果电脑长期不关机，wsl 跑点服务（诸如 redis ，nginx 之类），一旦碰到 windows 更新重启，会丢失桌面。

ltsc 、零售版都碰到同样问题。发生概率 1 年 3 次，出现在笔记本和 nuc 上。

多注意提交代码哈。真出现了 wsl 的文件基本无法恢复……

win11+ WSL2 体验挺好的, 开发在 win 中用 ide 连接 wsl 中的环境, 和 mac 体验差不多(还有显卡能调用

哈哈是的，我昨天也在想这个问题，小白看到网上的教程，安装完软件之后监听 0.0.0.0 ，localhost:xxxx 可以访问，但是局域网其他机器访问不到，如果不了解 WSL2 的网络隔离，怎么都不会想明白

这个我也遇到过，很多地方都得用 path.sep

感谢老哥提醒，我就是因为这类原因不敢把项目文件放在 WSL ，但是放宿主机就有文件 mode 777 的问题，闭环了

你难道不知道如今 win10 的路径风格是兼容 linux 路径风格的? 你完全按照 Linux 那套在 win10 下开发就是了

＃17 nvm 之类的东西可以解决

＃23 问题不大,我不跑这些服务,就跑个 cronjob, 这些服务我一般都用 docker 来搞.

windows 下 /app/就是 C:/app/, 你把 c 盘当做 linux 根目录来看待就是了

ojbk 我再体验体验

定时任务的话可以写脚本放到 windows 任务计划里自动运行。
传大量小文件话还是打包下再传会快很多，网络的话 wsl2 只会绑定到宿主机的 v6 地址，可以通过 localhost 访问，如果需要绑定到本机 127.0.0.1 的话可以看下这个 WSLHostPatcher

＃32 我不知道你是不是用的 wsl2, wsl2 下访问 c 盘是 /mnt/c 不会存在文件丢失的情况,也不需要 sync

这个可能没说清楚，代码如果放 WSL home 目录，git 环境没问题一切正常，不过根据楼上老哥的说法，Windows 大版本更新的时候会导致 WSL 挂掉，文件就丢了

所以我最早是把代码放宿主机，从 /mnt/c 访问，但是有俩问题，1. 文件权限全部是 777 导致 git 不正常 2. 宿主机传输文件速度慢的发指

＃35 -.- 我 win10 升到 win11 wsl 都没挂...

＃35 读取文件确实会有一些性能问题.

从 WSL 内拉取代码和新建文件就不会有 777 的问题了

能不能举个例子，我现在迷迷糊糊把 node 版本从 6 升到 12 好像都没遇到什么问题，node 哪些功能不做旧版兼容的么

某些版本的的 node 装某些版本的库，会有需要编译的情况，然后由于本机上可能配置对应的编译环境，导致安装失败。

不懂前端，不清楚为什么要用 wsl 。反正服务端表示真香。

＃39 我碰到一个窘境，node-sass 需要 node-gyp ，node-gyp 又有一大堆依赖，同时还不支持 node 15 往上。 最直接的方式就是弄个 docker image, 把代码考进去，每次跑容器就好了

FROM node:14-alpine as base
ENV HOME=/home/node
RUN apk add --no-cache python3 make g++ && \
yarn global add [email&＃160;protected]${VERSION} && \
yarn cache clean && \
node-gyp help && \
mkdir $HOME/.cache && \
chown -R node:node $HOME
USER node
VOLUME $HOME/.cache
WORKDIR $HOME
CMD ["sh"]

FROM base
WORKDIR /frontend
COPY package.json package.json
RUN yarn install
COPY . .
CMD ["npm", "start"]

现在流行 ship with environment 不是没有理由的， 越来越多的版本和各式各样的依赖，只要一个不对口，整个项目就跑不起来

systemd: github.com/arkane-systems/genie

其它经验参考: best33.com/403.moe

想起来了，我记得有个 cpu-features 的库，从来就没编译成功过，好像也没啥

＃29 我个人还是喜欢用 docker 去搞那些乱七八杂的环境，个人喜好吧

能在 Windows 配置的开发环境，感觉没必要迁移到 wsl ，平白无故要踩一些坑

＃44 以后的依赖库越来越复杂，版本越来越多，需要的环境也不一样，还可能出现库在网上消失和“被消失”。 严谨一些的 Golang 项目都把所有 import 在本地留一份。 所以我挺喜欢 docker 跑别人的项目， 不用担心我自己的环境被搞得乱七八杂的

条理清楚，方案可行，尤其是 「基于某种“不想在宿主机上安装开发环境”的奇怪洁癖矫情」就像是被偷窥了，晚上我就抄作业

我主要用就是，WSL 跑 docker ，然后用 docker 跑各种开发数据库安装卸载都很方便，无残留。 其他的 idea 提供的 wsl 的一些支持啥的都很弱，还有些问题，内存占用也太高，基本没法用。

不用 WSL ，就直接用宿主机就好。毕竟 wsl 还是远程开发范畴，而且还有各种问题。

我个人的经验：
1 、配置好系统代理和命令行代理，代理比各种换源方便太多
2 、用 winget 装软件（虽然比较新，但不少软件都有），部分软件自己去官网下载安装
3 、调整应用设置。chrome 、vscode 的同步功能很强（插件数据不太行），jetbrain 系有同步功能但比较弱。
4 、把文件放在家目录下，这样更通用，能省不少麻烦。
5 、用坚果云或其它同步工具同步一些附加的资源文件，如果有需要，配置一个类似于 NUTSTORE_FILES 的环境变量指向对应文件夹。
6 、写一个文档，记录一下配置过程，以备不时之需。

其实上面这个步骤在其它操作系统上也差不多，windows 需要做一些对应的调整而已。

我就是只在 WSL 开发的前端 [doge] WSL 里全放代码相关的各种东西，Windows 基本没有代码相关的东西，两边隔离的感觉针不戳。

如果项目真有可视化需求，之前在 WSL 里折腾 electron 没搞成功，不知道现在如何了，有需求再看。

winget 请， 装 IDE 跟着提示点点点就自动装好了，2021 了不用那么麻烦自己手动配置了

楼上 oott123 老哥分享了自己的博客，WSL 好像现在支持图形界面了，把 vscode 这类软件装进去估计也针不戳，有时间可以折腾下

没错的，宿主机肯定还是最方便

核心问题还是 WSL 的 777 问题，这个可以参考这个解决方案：

www.yuque.com/docs/share/30bbd704-4e6a-4386-93c8-577a104be557?＃ 《 WSL 中对文件权限进行设置》
windows 开发一般用 VSCODE remote 来搭配 WSL ，远程宿主机来使用，这样对 windows 的配置没太多的要求

WSL 总会碰到一些奇怪的问题，我选择用虚拟机装 linux

我个人看法是没必要为了用 WSL 而用 WSL ，现在用 Windows 已经很方便了，不过都是个人的选择，觉得 WSL 好用就用 WSL

最大的意義是：對於 linux 用戶來說，以後寫跨平台軟件可以忽略 windows 了，windows 用戶請自行使用 wsl 運行 linux 程序，反正 windows 用戶不怕麻煩

wsl 这个东西好像 开起来 关不掉~

大概浏览了一下，没有讨论图形化的吧？反正记得 WSL 好像有这个计划

为啥要用 wsl ？因为想用类 linux 的 shell 吗？建议试试 nushell

win11 的 wsl2 已经支持图形化了。

你既然用 git 了 还用 syncthing 备份干嘛，直接自动同步到 remote repo

格了上 Manjro

因为有些改动还不足以提交成 commit ，再就是像 .env 这种虽然不适合存 git 但是多台设备之间还是得同步的，最后就是同步盘用久了还真离不开 :D

对的，linux shell 是一方面，再就是开发环境和部署环境都用 linux 很有安全感，以前见过不少 mac 或者 windows 写的代码，到 linux 就跪

上次有个想法、就是本地开个虚拟机，WSL 或者 Multipass 开个 Ubuntu 、在虚拟机里面开服务端，用远程开发的方式连进去。。。但是这样就是资源占用爆炸。。。

nvm 可以管理不同版本 node

＃68 用什么管 python

wsl 用过一段时间，期间各种小问题不断，目前已经卸载 wsl ，回到 vmplayer 美滋滋

这是现目前只支持 win11 的意思？

歪个楼，我都是把所有编译环境放到 wsl 里，甚至 git 也在里面，本机上没有，CLion 的工具链设置到 wsl 里，或者偶尔 vscode 远程一下。通过 systemd-genie 这个项目实现 systemctl

github.com/ScoopInstaller/Scoop

Scoop 可以轻松的切换开发工具的环境，例如：

scoop install nodejs-lts
scoop install versions/nodejs14
scoop install python
scoop install versions/python27
node --version
v14.18.3
python --version
Python 2.7.18
python3 --version
Python 3.10.2
python2 --version
Python 2.7.18
scoop reset nodejs-lts
scoop reset python
node --version
v16.13.2
python --version
Python 3.10.2
python3 --version
Python 3.10.2
python2 --version
Python 2.7.18

如果你非要用 GNU/Linux 作为 OS 环境，可以试试 Vagrant 和 Multipass ，这两个也可以通过 Scoop 安装。

我用 wsl2 ，基本没遇到过什么问题。
唯一一次是编译时报 kernel syscall 问题，配置文件里加了一句解决。

主机上 wsl --shutdown

应该以后也是只有 win11 的 wsl2 支持，，

vscode+wsl2 搞嵌入式交叉编译感觉还行。。。。。。