如何使用 Windows 愉快的编程？

[willx12123]

我是一个 Web 程序员，Go 、Ruby 、Node 、前端。一切与 Web 相关的我都做（除了 PHP 哈哈）。

同时我也是一个 Windows 的喜爱者。可问题是我用 Windows 的事件越来越少——因为我无法在 Windows 上愉快的使用本地环境进行愉快的编程。

像我刚刚所列出来的几项语言，对 Windows 都很不友好，大家都优先选择支持 Linux 和 Mac——甚至是 M1 的 arm 环境。

• Ruby 就不多说了，老生常谈的 Windows 大坑。
• Node 的话，我一直以为它对 Windows 的支持还算挺好的，直到我今天发现 Hexo 的最新版本创建的项目就没办法在 Windows 正常启动……
• Go 的话，本身没啥问题，但是架不住很多人喜欢用 CGo ，这玩意儿要想在 Windows 上跑起来也是要费一番功夫的。

所以有用 Windows 写代码兄弟吗，能介绍一下在大家都首选支持 Mac 和 Linux 的情况下，你平时如何解决这些环境问题的吗？

[rekulas]

作为成年人，我们一般都要，开虚拟机映射本地 win 开发 linux 运行

[wilhelmvonchen]

wsl2

[i3x]

？？？不要搞混运行环境和编程环境。
开发环境包含了调试机器和编程机器。远程开发并没有什么问题。在 windows 运行这些东西当然很麻烦。

我在 windows 编辑。在目标机器调试。为什么要在自己的编程电脑开发调试呢。

我从来不在本地运行调试代码。除非是临时搞个 win 的小工具。
哪怕 php 也不会放在 windows 。何况 go python 之类的。这些东西引入了一些依赖到时候清理维护多麻烦，而虚拟环境也不是万能的。直接远程虚拟机或者本地开虚拟机，环境如果需要侵入式修改，有问题直接快照回退一秒就 ok 。虚拟机快照为开机状态，一秒就进入状态，多方便。

[willx12123]

@rekulas 我用过一段时间 Docker ，别的体验还可以，但 Node 项目很不好弄，因为 node_modules 依赖和工程文件在一起。。。跨系统下载、写入大量小文件，整的 Node 项目的依赖都下不下来

[cmdOptionKana]

- Ruby 只是小坑吧？
- Hexo 的问题不能算 Windows 的问题，一大堆 Node 项目在 Windows 里没问题。
- CGo 只要下载 TDM-GCC ，双击安装，一路点下一步确定即可，也不算麻烦（相当于安装一个软件而已）。

还有什么问题？

[rekulas]

@i3x 赞同，说实话不太建议用 wsl 之类的，因为我们之前就遇到过一些坑，跟真实环境有差异，虚拟机要靠谱很多

[willx12123]

@i3x 请教下，有什么和虚拟机同步工程代码的工具推荐吗，Jet Brains 那个 SFTP 同步总是出问题，老少同步东西

[Buges]

@cmdOptionKana 看看这个项目的下载量 https://www.npmjs.com/package/cross-env

[willx12123]

@cmdOptionKana Ruby China 的公告里都说的新手不要用 Windows hhhhh

[jsq2627]

WSL2 ，现在是我主力开发环境。跑公司复杂的 node / ruby / go / rust / python 等项目基本没啥问题。

[willx12123]

@cmdOptionKana 主要是没碰到就是小概率，碰到了就是大坑。。。Windows 碰到大坑的概率就比其他俩系统高太多。。。

[i3x]

@rekulas +1
既然最重要为线上服务所以肯定是直接高仿线上环境。wsl 跟线上差远了。


@willx12123
实在不行就共享文件夹。windows 挂载 linux 除了 samba nfs 客户端，甚至还可以 sshfs 。性能都不赖的。当我需要批量替换变量名称的时候，比本地固态硬盘还能快一些。

[duzhor]

除开开发环境，生活娱乐方面 windows 已经很方便并且大家都习惯了，考虑虚拟机、云服务器作为单独的开发环境，远程或者 ssh 连接

[cmdOptionKana]

@willx12123 这篇文章 https://ruby-china.org/topics/1020

列出的理由有 6 个大点，好几十个小点，其中只有一个小点 “每年解决 Windows 上的奇怪问题” 是说 Windows 的问题（就这么一句笼统在话，没有具体细节），其余全部都是类以使用习惯之类的。


@Buges 这个项目只是解决使用习惯的问题，错不在 Windows 系统吧？

[zhuangzhuang1988]

那就选择 windows 友好的语言比如 c# java php 啥的。

[treblex]

vs code: remote wsl, remote server, remote docker

[ychost]

试试 C# 吧，配合 VS 直接起飞🛫

[Buges]

@cmdOptionKana 这个项目只是 Windows 上踩坑的一种体现。你要说错也没什么错的，哪个程序不支持 Windows 或在 Windows 上有 bug 也不能怪 Windows 啊。

[walpurgis]

win 本地环境不值得折腾，否则微软也不会花那么多代价去搞 wsl
现在发展方向就是远程开发，让在远程开发像编辑本地项目一样，vscode remote 已经非常完美了，JB 家的还在 Beta ，能用，但 bug 还很多，需要经常重启，估计再过个半年一年就能成熟稳定了

[FrankHB]

可以默认用 WSL 。
嫌弃虚拟机麻烦（比如 IP 地址莫名其妙啦……），就 WSL1 （ WSL2 本质就是个 HyperV 虚拟机实例），虽然有些限制，大多数还算能用。
例外情形：
若你需要开发 Linux 内核模块本机调试之类，那当然没办法；
用 fuse 之类也可能比较麻烦；
偶尔会有些系统调用实现残缺不可用；
不要指望 systemd 之类的东西完整可用（同等层次上依赖系统实现细节的还有 nix 等）；
GUI 多少比原生 Win32 麻烦且可能有无解的细节问题（例如输入法之类），性能可能也不咋地（ WSLg 需要 Win11+WSL2 ），但 VcXsrv 跑个别应用基本上够用；
其它情况下，和原生 Linux 的差异是否能被容忍，取决于你自身对环境的理解（觉得不保险嫌弃麻烦那还是虚拟机了）。

如果要更原生的体验，用 MSYS2+MinGW 。
警告（相对 WSL ）：原生 Win32 的构建性能会普遍降低；
小文件 I/O 性能会极其感人；
即便排除 I/O 问题，也不要指望 node.js 之类的运行时的表现不会明显变差；
同时，可能处理一些表面上容易遗漏，实际 Win32 特有的屑问题，大多是关于文件系统的：
Win32 的默认机制导致打开程序不能删除，这有时候很欠揍；
默认创建符号链接可能需要管理员权限，需要组策略变通；
Win32 不支持无视 AUX 这样的 DOS 保留文件名（但 MSYS 的工具能提供一些变通）；
可能必须需要 fsutil 单独设置大小写兼容。

如果你要继续完全原生地使用 Win32 ，那么基本不会有更好的体验（以上 WSL 解决了的 Win32 问题会继续存在），并且有些问题是无解的。

@cmdOptionKana 这篇文章有些是很扯蛋的，或者至少是过时了（即便考虑原文时间无视 WSL ）。

像工具方面：
很多都是 Win32 自己残废，而不是命令行；
Win32 的残废如果不是需要自己积极变通，是可以改用现有工具在 Windows 上的移植而无视的；
如 git 的不好用，大多是因为 git 自身而不是 Windows 上的实现（除了一些 I/O 性能问题）。

在如，第五点几乎全是在 FUD ，不知道是在黑 Windows 还是黑 Linux 。