零、前言#

每次我写这种文章，总会有人跳出来说：“bro 你又偏激了！”、“Windows 现在已经很好了！”、“WSL 启动！”。

现在是 2026 年，不是 2006 年，也非 2016 年。二十多年过去了，Windows 在严肃的程序开发这件事上，依然是一个彻头彻尾的笑话。不是因为微软不努力，而是因为它的根是烂的。把一棵树的树根泡在福尔马林里，树冠上挂再多 LED 灯也没用。

2026 年，曾经被认为是 精神病人 的 macOS 游戏玩家已经可以玩不少 3A 大作。那个 “Linux 不能玩游戏” 的 Linux —— 已经成为最适合玩游戏的操作系统。Steam Deck 卖了几百万台，Wine / Proton 让 Windows 游戏在 Linux 上跑得比在 Windows 上还快。

游戏，这个 Windows 曾经唯一的护城河，几乎被攻破了。

而 Windows 呢？它连 “用来开发” 这件事都做不好。

一个用来在星巴克剪视频的操作系统现在更适合开发，一个用来开发的操作系统现在更适合玩游戏。世界颠倒了，但 Windows 还是那个 Windows，至死不渝。

你的合作者用 Linux 和 macOS，你用 Windows —— 恭喜你，自动成为了团队里的 “那个麻烦”。

一、路径分隔符#

在 Linux 和 macOS 上，路径是 /home/JH/project/src/main.c。在 Windows 上，路径是 C:\Users\JH\project\src\main.c。

就是这个字符，让你的人生比其他人多出 33% 的烦恼。你在代码里写 path.join("build", "output")，在 Python 里用 os.path.join，在 C++ 里用 std::filesystem::path::preferred_separator —— 你觉得你处理好了。不，你没有。

总会有某个库、某个脚本、某个第三方工具 硬编码 了 "/" 或者 "\\"。写 path/to/file 在 Windows 上可能侥幸能跑，但把路径传给 cmd.exe 的时候，不认。传给 cl.exe 的 /I 参数的时候，偶尔不认。传给某个用 CreateFileA 的古老工具时，绝对不认。

更糟糕的是，你的 Linux 队友写了个 CMake 脚本：

1
set(OUTPUT_DIR "build/${CONFIG}/obj")

你高高兴兴拉到 Windows 上一跑，CMake 把它变成了 build\Debug\obj。看起来没问题？等你把这个路径传给一个用 Python 的 pathlib 生成的东西，再传给一个用纯字符串拼接的东西，再经过三层脚本 —— 恭喜，你得到了 build\\Debug\\obj 和 build/Debug/obj 混在一起的奇观。构建系统开始报“找不到文件”，你花两个小时发现是某个 shell 脚本里有一行 sed 's/\//\\/g' 写错了。

你的 Linux 队友不用想这些。你的 macOS 队友也不用想这些。只有你。

你用 Nushell 或者 PowerShell Core？Nushell 是结构化 Shell，它懂表格，懂数据流，但它不懂为什么 Windows 的世界里到处都是反斜杠。启动是快了，试试在里面执行一个 Windows 原生命令，返回一个路径 —— 给的是 C:\Users\JH\project。你要把这个路径传给下一个命令，下一个命令期望的是 C:/Users/JH/project。或者反过来。你可以在脚本里用 str replace 把 \ 换成 /，但你每写一个 pipeline 都要做一次。你的脚本变得又臭又长。

你的 Linux 队友，打开终端，瞬间。输入命令，路径永远是 / 分隔，永远不会错。他们不知道你在经历什么。

二、cl.exe 和 MSVC 构建工具：活在 1995 年的编译器#

有人说 “Windows 上可以用 clang 啊”。可以，当然可以。但用 clang for Windows，你链接的是什么库？还是 MSVC 的运行时库。避无可避。

MSVC 的问题不在于它不符合标准（虽然它曾经很烂，现在依然有一些角落烂着），而在于它的 工作流。

在 Linux 上写 gcc main.c -o main，完事。在 macOS 上写 clang main.c -o main，完事。在 Windows 上？

首先，你得找到 cl.exe。它不在 PATH 里。你得打开 “Developer Command Prompt”，或者运行 vcvarsall.bat。这个脚本干了什么？设置了二十几个环境变量，修改了 LIB 和 INCLUDE 路径，还把一堆莫名其妙的东西塞进 PATH。

想自己配？那你告诉我，cl.exe 需要的 mspdbcore.dll 在哪？vcruntime.h 在哪？kernel32.lib 在哪？你不知道。我也不完全知道。微软自己把它藏在一个每六个月变一次路径的目录里：C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64。你感受一下。

然后你说 “我用 CMake”。好，CMake 能帮你找到这些东西。但 CMake 自己也要先知道用哪个 generator。你用 -G "Visual Studio 17 2022"，CMake 生成了一大堆 .sln 和 .vcxproj 文件。这些文件是 XML。巨大无比。你打开看一眼就想吐。你不想用 Visual Studio IDE，你只想用命令行。但 MSVC 的命令行生态是 二等公民。

最可笑的是预编译头。在 Linux 上没人用预编译头，因为编译速度没那么慢。在 Windows 上不用预编译头？#include <windows.h> 一个头文件展开后几十万行，再 #include <iostream> 又是几万行。你的编译速度慢得像是在用软盘装系统。而 MSVC 的预编译头机制 —— /Yc 和 /Yu——复杂到专门有一本书的章节讲它。而且它在命令行下用起来别扭得要死。

你花在工具链上的时间，你的 Linux 队友用来写 feature。

三、Rust 工具链#

有人说 “我在 Windows 上用 Rust 开发体验很好”。是的，体验很好。但你知道这个 “很好” 是怎么来的吗？

Rust 为了在 Windows 上找到 cl.exe 和相关环境，专门写了约 2000 行代码，一整个专门的 package。你以为 cargo build 能直接工作是理所当然的？不是。那是 Rust 工具链的维护者替你受了你本该受的苦。

在 Linux 上写 cargo build，它调用 cc，cc 调用 gcc 或者 clang，完事。三行逻辑。

在 Windows 上写 cargo build，背后是一台用胶带和铁丝绑在一起的 Frankenstein 怪物。而 Rust 团队花了无数个日夜，让这个怪物看起来像个正常人。

你觉得体验好，是因为有人替你挡了子弹。和 Windows 毫无关系。

四、LF vs CRLF：一场持续五十年的愚蠢战争#

这是最让我无语的一个问题。它本来不应该存在。

Unix 用 LF（\n，0x0A）表示换行。古老的 Mac OS 9 用 CR（\r，0x0D）。Windows 用 CRLF（\r\n，0x0D 0x0A）。

为什么 Windows 用 CRLF？因为 MS-DOS 抄袭 CP/M，CP/M 用 CRLF 因为它的文件系统用 CRLF 来 “兼容 TTY（电传打字机）”。TTY，你听听，电传打字机！！

现在是 2026 年。谁还用电传打字机做终端输出？没有。但 Windows 记事本 —— 直到 2018 年 —— 都不支持 LF 作为换行符。你打开一个 LF 结尾的文件，它会显示成一行。整个文件粘在一起。后来微软改了，但那是 2018 年！距离 Unix 发明已经过了 49 年。

你以为现在没问题了？Naive!

Git 有 core.autocrlf。你设成 true，它会在 checkout 时把 LF 转成 CRLF，commit 时转回 LF。看起来很美。但你会遇到：

• 一个 shell 脚本里有 #!/bin/bash，它要求文件以 LF 结尾。Git 把它转成了 CRLF，bash 不干了。
• 一个 JSON 文件里嵌了换行符，你的解析器逐字节读，发现多了一个 \r，JSON 解析失败。
• 你的 Python 脚本用 open("file", "r") 打开一个 CRLF 文件，在 Linux 上读出来每行末尾有 \r，你 strip 了吗？没有，于是你比较字符串的时候永远相等不了。
• 你的队友不小心提交了一个 CRLF 文件，你用 git diff 看到整个文件每一行都被修改了。因为 diff 工具认为每一行末尾多了一个看不见的字符。

你在 Windows 上配 .gitattributes 配到怀疑人生。你设 * text=auto，又设 *.sh text eol=lf，又设 *.bat text eol=crlf。然后你发现 .gitattributes 自己也被转成了 CRLF，导致 Git 不认这个文件。

你的 Linux 队友从不思考这个问题。他写代码，commit，push。你 pull 下来，所有文件都在报错。你花半天时间 dos2unix 整个目录，commit，push。你的 macOS 队友 pull 下去，他的编辑器显示 “文件格式混合”。他开始骂你，你开始骂 Windows。

而 Windows 说：“我们有 WSL 啊，你在 WSL 里开发不就好了？”

五、WSL 不是答案#

每次说到这，总有 Windows 粉丝说 “你用 WSL 啊”。我建议你把 WSL 的全名念一遍，WSL 是 Windows Subsystem for Linux。

WSL 1 是翻译层，把 Linux 系统调用翻译成 Windows 系统调用。慢得一塌糊涂，I/O 性能像在爬。

WSL 2 跑了一个真正的 Linux 内核在 Hyper-V 虚拟机里。性能好了，但你的文件在哪？你在 /home/JH/project 下，这个目录实际在虚拟硬盘文件里。你想访问 Windows 的 C:\Users\JH\project？可以，它在 /mnt/c/ 下面。但访问 /mnt/c/ 的性能 又回到了 WSL 1 的水平，因为要经过 9p 协议来回转换。

所以你在 WSL 里工作的最佳实践是什么？把代码放在 WSL 自己的文件系统里。也就是说，你不用 Windows 的文件系统了。你的编辑器呢？你可以在 Windows 上用 VS Code 连接 WSL，通过 Remote - WSL 插件。VS Code 在 Windows 上跑界面，后端在 WSL 里跑。

等等，那你的开发环境到底算 Windows 还是 Linux？你调试一个程序，它在 WSL 里跑，但你用的工具链是 Linux 的 gcc，链接的是 Linux 的 .so 文件，生成的是 Linux 的 ELF 二进制。这个二进制在 Windows 上跑不了。你想生成 Windows 的 exe？那你得退出 WSL，回到 Windows，用 MSVC。

所以 WSL 不是让你在 Windows 上开发 Windows 程序。它是让你在 Windows 上开发 Linux 程序。换句话说，你用 Windows 作为宿主机，跑一个 Linux 虚拟机，然后在虚拟机里开发。那你为什么不直接装 Linux？

WSL 的存在说明：微软承认 Windows 的开发体验不如 Linux，所以他们给你一个 Linux 虚拟机。但你每多一层抽象，就多一层麻烦。网络配置、设备映射、环境变量传递、进程间通信 —— 每一个都有一堆奇怪的边界情况。

这就好比你说 “我想学游泳”，然后有人给你买了一个游泳池，但游泳池里没有水，水在隔壁的另一个池子里，你得用一个桶把水拎过来。你问 “为什么不直接在那个池子里游泳”？他说 “因为那个池子太丑了”。

六、摩登的 PowerShell#

你说你用 PowerShell。好，我问你：你打开一个终端，输入 powershell，回车，然后呢？

等…

等……

等………

等五秒钟。等六秒钟。有些配置稍差的设备，甚至能等十秒。

你告诉我，你在一台 CPU 是 5GHz，内存 64GB，NVMe SSD 的机器上，启动一个 Shell 要五秒钟。这不是开玩笑吗？五秒钟够 Linux 启动整个系统了。

为什么？因为 PowerShell 启动时要加载 .NET 运行时。.NET 运行时要 JIT 编译一大堆代码。它要加载几百个 DLL。它要读取你的 profile 脚本。它要做一百件你根本不关心的事情。

你说 “那我用 Nushell”。Nushell 启动只要 9 毫秒。你算算：5000 毫秒除以 9 毫秒，555 倍。这是什么概念？PowerShell 用户眼里的 Nushell 就像普通人眼里的 Faiz 加速形态。

七、MSVC Build Tools：许可证问题让你无法自动化#

这可能是最荒谬的一点。

你想在 CI/CD 里自动构建 Windows 程序。你在 Linux runner 上交叉编译？不行，你缺 MSVC 的 headers 和 libraries。

那你怎么办？你需要安装 MSVC Build Tools。你怎么安装？你去微软官网下载 vs_BuildTools.exe，然后手动点击下一步、下一步、同意许可协议、勾选组件、等待安装。

你不能用 winget 自动安装。你不能用 Chocolatey 自动安装（虽然社区有包，但不是微软官方支持的）。你不能在 Docker 镜像里预装（除非你用 Windows 容器，那又是另一个地狱）。

MSVC Build Tools 的许可证不允许你以编程方式绕过安装程序的 “技术限制”。你可以自己写脚本调用静默安装参数，但那不叫 “自动化”，那叫 “我帮你点下一步” —— 你依然需要一个交互式会话或者预先配置好的镜像。

在 Linux 上装 gcc：apt install gcc。一条命令，不需要点击任何东西，不需要同意任何许可协议，不需要等待一个蜗牛般的下载。

微软为什么不能把 MSVC 工具链放到一个简单的 .tar.gz 里？因为许可证不允许。因为微软希望你用 Visual Studio IDE。因为命令行用户是二等公民。从 1990 年代到现在，一直是。

八、GBK 编码：一个本该在 2006 年死去的东西#

写中文注释。处理中文文件路径。你的队友在 macOS 上提交了一个包含中文字符的 JSON 文件。

恭喜你，触发了 Windows 最恶心的 “特性” 之一：GBK 编码。

在 Linux 和 macOS 上，文本文件默认是 UTF-8。从 2000 年代初就是这样。今天是 2026 年，UTF-8 已经是绝对的主流，全世界 98% 的网页用 UTF-8。

Windows 呢？Windows 的 “ANSI 代码页” 默认是 GBK（如果你在中文系统上）。你用记事本保存一个文件，默认编码是 ANSI（也就是 GBK）。你用 PowerShell 输出重定向，默认编码是 UTF-16LE（不是 UTF-8）。你用 cl.exe 编译一个源文件，如果源文件是 UTF-8 with BOM 它能认，没有 BOM？它当成 ANSI 处理，然后你的中文字符串变成了乱码。

你的 Linux 队友提交了一个 UTF-8 文件，你拉下来用 VS Code 打开，VS Code 猜编码猜错了，你看到一堆 ä½ å¥½。你手动改编码，保存。然后你的队友拉下去，发现文件变成了 CRLF（我们后面说这个）加 UTF-8 with BOM。他开始骂你。

你在 Python 脚本里写 open("file.txt", "r")，在 Linux 上读 UTF-8，在 Windows 上读 GBK。你的脚本 “在我电脑上能跑”，在你队友电脑上崩了。

你说 “那我用 Python 的 encoding='utf-8' 参数”。你知道你要写这个参数，你写了。但你调用的第三方库呢？它没写。你的构建脚本里的某个工具呢？它没写。总有某个地方，某个人，某段代码，默认用了系统 ANSI 代码页。

这个问题从 Windows 95 时代就存在。30 年了。没有解决，且永远不会解决。

九、LLM Agent 时代的致命伤#

这是 2026 年才变得特别明显的问题。

你让一个 LLM Agent 比如 Claude Code、OpenAI Codex 帮你执行一条命令。在 Linux 上，Agent 写 grep "hello world" file.txt，直接执行，成功。

在 Windows 上，Agent 写 findstr "hello world" file.txt，执行，成功。看起来不错。

然后你让 Agent 执行一条稍微复杂一点的命令：

1
powershell -Command "& { Get-ChildItem -Recurse | Where-Object { $_.Name -match 'test' } }"

问题来了。引号嵌套。Agent 不知道什么时候用双引号，什么时候用单引号，什么时候转义。PowerShell 的语法是出了名的 “写起来像英语，转义起来像咒语”。

你让 Agent 生成一行 C++ 代码并通过 cl.exe /D 传入：

1
cl /D"MY_STRING=\"hello\\nworld\"" main.c

你需要两层转义：一层给 shell，一层给 C 预处理器。在 cmd.exe 里，转义规则和 PowerShell 不一样。在 PowerShell 里，转义规则又不一样。在 Git Bash 里，又不一样。

Agent 试了三次，都失败了。它开始 “深度思考”，写了一个 Python 脚本来生成命令，然后执行 Python 脚本——绕了一个大圈子。你的 token 消耗从 100 变成了 5000。没关系，Windows 用户的 token 是大风刮来的。

你的 Linux 队友的 Agent 从未失败过。因为 Linux shell 的转义规则是清晰的、一致的、可预测的。Windows 有四种不同的 shell（cmd，PowerShell，Git Bash，WSL bash），四种不同的转义规则，每一种都有自己的 “惊喜”。

十、关不掉的 Windows Defender#

你说你的编译慢。你说你的 npm install 慢。你说你的 git clone 慢。

我告诉你原因：Windows Defender 在扫描每一个文件。

你编译一个 C++ 项目，生成 1000 个 .obj 文件。Defender 在每个文件创建时扫描一遍。在每个文件写入时扫描一遍。在链接器读取每个文件时再扫描一遍。

你在 Linux 上编译同一个项目，没有这些扫描。编译时间差多少？首席水煮牛肉师实测，同一台设备，物理安装 Linux + XeLaTeX 编译一份 .tex 文档，比 Windows 快 80%。

80%！这意味着你在 Windows 上等 10 分钟，在 Linux 上等 2 分钟。一天编译 20 次，你浪费了 160 分钟。将近三个小时。

那我关掉 Defender？你试过吗？你知道怎么关吗？

你可以去 “Windows 安全中心” 关掉 “实时保护”。五分钟后它会自动重新打开。你可以在组策略里禁用。但 Windows 10/11 的家庭版没有组策略。你可以修改注册表。但下一次 Windows Update 会把它改回来。你可以装一个第三方杀毒软件，Defender 会自动关闭 —— 但你现在不仅要对付 Defender，还要对付另一个杀毒软件。

能不能完全永久关掉？不能。Windows 不允许你关掉它最核心的安全功能。这是“为了你好”。微软替你做了决定。

你说 “那我把编译目录加到排除列表里”。可以。但你做 CI/CD 的时候呢？你的构建机每次都是新的，排除列表每次都要重新配置。你的 Docker 容器里跑 Windows？排除列表在容器里不生效。

而在 Linux 上，安全是你的责任。你想关 SELinux？setenforce 0。你想关 AppArmor？systemctl stop apparmor。系统听你的。Windows 不听你的。Windows 是你的 Master，你不是它的用户。

十一、NTFS 和 ReFS 的悲剧#

在 Windows 上编译一个项目，生成几千个小文件。慢到怀疑人生。

你把项目放到 Dev Drive 上（微软 2023 年推出的“开发者专用”分区格式，基于 ReFS）。快了一点。但为什么还是比 Linux 慢？

因为问题的根源不是文件系统格式，是 安全软件插在文件系统上的那些钩子 （filters/hooks)。Dev Drive 之所以快，是因为 Windows 默认不对 Dev Drive 上的文件进行某些安全检查。但即使这样，Linux 在处理大量小文件的场景下依然比 Windows 快得多。

Linux 的文件系统设计从一开始就考虑了 “很多小文件” 的场景。ext4、XFS、btrfs，它们的目录结构、inode 管理、缓存策略，都是为真实世界的工作负载优化的。

NTFS 的设计目标是 “与 DOS 和 Windows 95 兼容”。它的根目录下还有 C:\、D:\ 这种盘符的概念——这是 1970 年代的 CP/M 遗留的设计。你什么时候在 Linux 上见过盘符？没有。/mnt 和 /media 是挂载点，不是盘符。

你说 “那我用 WSL 2，把代码放在 WSL 的文件系统里”。是的，这样快。但你本质上是在用 Linux 的文件系统。那你为什么不直接装 Linux？

Windows 的文件系统性能问题不是 “差一点”，是 “差一个数量级”。你编译一次可能只差几十秒，但你一天编译几十次，一周五天，一年五十二周——算算你浪费了多少生命？

十二、Windows 11 的内存黑洞#

你说你的电脑是 8GB 内存。你说你只是想写写前端代码。

8GB 内存在 Windows 11 上连 “开机后什么都不做” 都勉强。

Windows 11 开机后，系统自身吃掉 3-4GB。Windows Defender 吃掉 500MB。Windows Update 服务吃掉 200MB。各种 “现代” 应用的后台进程——天气、新闻、Xbox、Your Phone、Cortana*（对，它还在）*加起来又是 1GB。

你已经用了 5-6GB。你打开 Chrome 或 Edge？一个 tab 100MB 起，开十个 tab 就是 1GB。你打开 VS Code？又一个 500MB。你打开 Docker Desktop？2GB 没了。你的内存开始 swap。swap 到 SSD，SSD 寿命下降。你的电脑开始卡。

你说 “那我加内存”。好，你加到 16GB。Windows 11 会咸因吗？不会。它会用更多内存来 “缓存” 东西，因为它的内存管理策略现在是 “有多少用多少”。你打开任务管理器，看到 “已提交” 内存是物理内存的两倍。你问系统管理员这是怎么回事，他说 “You’re Absolutely Right!”。

正常？你在 Linux 上跑 free -h，看到 used 是 2GB，cached 是 4GB，available 还是 4GB。你清楚知道内存去哪了。Windows 的 “资源监视器” 给你看一堆数字，你看了三遍也不知道到底谁吃了你的内存。

更可笑的是，Windows 11 的推荐配置是 4GB 内存。4GB！安装都装不进去 —— 安装程序自己就要 2GB，还要留空间解压文件。微软的硬件兼容性团队是不是在用 8 + 128 (8TB SSD + 128GB RAM) 的机器测试，然后写文档的人觉得是 8 + 128 GB，才能如此心安理得地写下 推荐配置 4GB？

十三、WebView UI 把操作系统变成浏览器#

Windows 11 最 “现代” 的特性是什么？WebView UI。

设置界面是 WebView。开始菜单是 WebView。文件资源管理器的部分界面是 WebView。通知中心是 WebView。任务栏的 “小组件” 是 WebView。

没错！你的操作系统，现在是用 HTML、CSS 和 JavaScript 渲染的。

你打开 设置 → 个性化 → 颜色。你点了 “深色模式”。UI 卡了 0.5 秒。为什么？因为它要重新渲染整个 WebView 页面。你在 Linux 上改个 GTK 主题，瞬间生效。因为 GTK 是原生渲染。

WebView 有什么问题？

• 内存占用翻倍。每个 WebView 实例是一个迷你浏览器，有自己独立的渲染进程。设置界面是一个实例，开始菜单是一个实例，小组件是一个实例。每个实例吃掉 100-200MB 内存。你的 8GB 机器就这样被一点点蚕食。
• 渲染延迟。你点击“开始”，等 0.3 秒菜单才弹出来。不是动画时间，是 WebView 响应时间。你在 Linux 上用 KDE 或 GNOME，点击开始菜单，瞬间弹出。因为那是原生代码，不是 JavaScript。
• 动画掉帧。你打开通知中心，动画掉到 30fps。你问微软为什么不优化，微软说 “我们用 Fluent Design 的流畅动画”。流畅？30fps 叫流畅？你在 macOS 上打开通知中心，ProMotion 120fps 丝般顺滑。Windows 11 的 UI 性能甚至不如 2015 年的 Windows 10，而 Windows 10 的性能不如 2012 年的 Windows 8/8.1。开倒车，而且是坐着火箭开倒车。

一个操作系统，连自己最基础的 UI 都做不好，你指望它能做好开发体验？

十四、微软官方承认的 boot loop 特性#

2025 年，微软官方发布了一篇支持文档，标题是 “Windows 更新后可能出现 boot loop”。

你再读一遍这句话。

微软官方承认，他们的操作系统在更新后可能会 boot loop。

你的电脑开机，启动 Windows，加载更新，重启，开机，启动 Windows，加载更新，重启 …… 循环往复，直到你手动进入恢复模式，卸载更新，或者重装系统。

2025 年，微软说 “我们正在修复这个问题”。

2026 年，这个问题依然存在。

你在写代码，Windows 提示 “需要重启以完成更新”。你说 “稍后”。Windows 不听你的，因为 Windows 作为大总统的权力是无限的。Windows 在凌晨 3 点自动重启了。你的工作没有保存。你的 IDE 没有恢复会话。你的本地 git 仓库可能有未提交的变更。全是你的责任，你用 Windows 这个权力无限大系统应该承受的责任。

第二天早上你打开电脑，看到 “正在配置更新 0%”。你等。等到 30%。它重启。又开始 “正在配置更新 0%”。

你这一天废了。你要花两个小时进入恢复模式，卸载更新，然后关闭 Windows Update 服务。你的 Linux 队友已经提交了三个 PR 然后超额完成任务给自己放假了。

你说 “那我用 Windows LTSC 版本，没有这些花里胡哨的更新”。好，但你用的是企业版，你的公司不一定买。而且 LTSC 版本三年才更新一次，你的开发工具需要的新 API 没有。你装个 Node.js 18，它说 “需要 Windows 10 1903 或更高版本”。你的 LTSC 是 1809。你又被卡住了。

Windows 是一个强制性的、不可预测的、可能摧毁你工作进度的操作系统， 其中 “操” 念第四声。你永远不知道它什么时候会来，来了之后会不会把你的系统搞崩。

十五、最大的讽刺，最好的游戏系统#

这是起点，亦是终点。

2000 年代，Windows 的护城河是什么？游戏。你想玩游戏？你必须装 Windows。Linux 上连《魔兽世界》都跑不了，macOS 上更别想。那时候的 Windows 用户嘲笑 Linux 用户：“你的系统能玩 3A 大作吗？或者 Galgame？”

2026 年，情况完全反过来了。

• Steam Deck 卖了几百万台，跑的是基于 Arch Linux 的 SteamOS。
• Wine / Proton 让成千上万的 Windows 游戏在 Linux 上无缝运行。很多游戏在 Proton 下的性能甚至 超过原生 Windows，因为 Vulkan 翻译层比 DirectX 在某些场景下更高效，也没有无数次生生不息的 Defender 扫描，也没有残废的文件系统。
• NVIDIA 和 AMD 的 Linux 驱动已经成熟到可以跑光线追踪。
• macOS 游戏玩家 —— 就是那群被嘲笑了二十年的 “用 Mac 玩游戏的精神病人”，现在已经可以通过 Game Porting Toolkit 玩不少 3A 大作。苹果甚至官方支持这件事。

游戏。Windows 最后的堡垒，几乎已经沦陷了。

而 Windows 呢？它在开发领域依然是一团糟。你在 2026 年用 Windows 开发，你要面对：

• 路径分隔符的混乱（来自 1980 年代的 DOS）
• CRLF 换行符（来自 1970 年代的 CP/M）
• MSVC 工具的许可证地狱（来自微软的商业模式）
• PowerShell 五六秒的启动时间（来自 .NET 的包袱）
• GBK 编码（来自中国区 Windows 的特殊 “待遇”）
• Defender 关不掉的 I/O 拖累
• 四种 shell 四种转义规则
• 8GB 内存不够开机（来自 Windows 11 的 “现代化”）
• WebView UI 卡成 30fps（来自 “我们也是 Web 公司” 的幻觉）
• boot loop（来自微软官方承认的 bug 特性）

你的 Linux 队友在做什么？TA 在 Arch 或者 NixOS 上全成就通关《魔法少女的魔女审判》，在《鸣泣之时》中听着志方晶子志仓千代丸作的曲子看沙都子大战梨花，在《素晴日》里穿着轻飘飘的衣服于楼顶上抽烟，切到桌面，gcc main.c -o main，完事。

你的 macOS 队友在做什么？TA 在 MacBook Pro 上打开《赛博朋克 2077》《死亡搁浅 2》《生化危机》《博德之门 3》《艾尔登法环》《巫师 3》《无人深空》，关掉，clang main.c -o main，完事。甚至还有余力剪辑游戏录屏然后发到 B 站。

你呢？笔电男大？你在等待 PowerShell 启动，你在等待 Windows 启动，但有时它们永远也不会启动，像极了在一代杀戮尖塔玩鸡煲的你。你在跟 CRLF 搏斗。你在想 cl.exe 你到底在哪，cl.exe 你根本不在 C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64，你在想 cl.exe 为什么会和 nvcc、cygwin 撞车。你在想 Everything 为什么能在你本地搜出 11 个 ghc 安装目录下的 MSYS2。你在考虑要不要把编译目录加到 Defender 排除列表里，你在想要不要重装一个更稳定的第三方修改版 Windows。你在 Stack Overflow 上搜 “vswhere 找不到 Visual Studio”。你的电脑在 boot loop。你的 UI 在掉帧。你的内存被 WebView 吃光了。你打开 IM 尝试求助群友，但是每个人都在发 “喜报” 图片。

你想你的 Arch Linux 了。

帕特玛颠倒了，世界颠倒了。但 Windows 没变。

后记#

有读者问我 “你是不是对微软有偏见”。我对微软没有任何偏见。我对任何浪费我时间的工具有偏见。Windows 是其中最突出的一个，MS Office 也是，不过这是另一个话题了。

还有读者问 “2026 年了，你还用 Windows 吗？”

用。为了写出这篇文章，我还得用。