Windows 为什么还在用反斜杠：一个字符背后的兼容性债务

Windows 路径里的反斜杠不是审美选择，也不是微软故意和 Unix 作对。它更像一枚化石：DOS 1.x 时代先把正斜杠用作命令参数前缀，DOS 2.0 引入子目录时又必须找一个不会破坏旧程序的路径分隔符，最后只剩反斜杠能安全落地。

这个细节之所以值得反复讲，不是因为一个字符多有戏剧性，而是因为它说明了软件系统里最难改的东西往往不是算法，而是已经扩散到用户、脚本、文档、工具链和商业承诺里的兼容性。

路径分隔符的真正约束来自旧生态

Unix 早早把正斜杠作为目录层级分隔符，这个选择后来被 Linux、macOS 和大量网络路径习惯继承。DOS 的路径历史则绕了一圈：最早的 DOS 1.0 没有子目录，正斜杠主要承担命令选项前缀，例如类似 DIR /W 的写法。

等 DOS 2.0 需要支持硬盘和目录层级时，正斜杠已经被大量现有命令、批处理和第三方程序占用。理论上可以强行改，但实际代价是让已售机器和软件生态出现大面积不兼容。工程团队最后选择反斜杠，本质上是用一个小别扭换取旧生态继续运行。

为什么后来也没有统一回去

很多开发者不知道，Windows 的不少底层 API 和运行时场景其实能接受 C:/Users 这种正斜杠路径。问题在于“能接受”不等于“能改默认”。默认语法一旦改掉，受影响的不是一个 API，而是命令行、文档、批处理、安装脚本、注册表、企业自动化和无数教程。

兼容性不是一次开关，而是一条漫长供应链。微软可以让新 API 更宽容，却很难让整个生态同时忘掉四十年的写法。

今天写跨平台代码该怎么处理

第一，不要手拼路径。Node 里用 path.join/path.resolve，Python 用 pathlib，Java 用 Path/Paths，Go 用 filepath。第二，区分文件系统路径和 URL：URL 永远用正斜杠，Windows 本地路径不应该被直接拼进 URL。第三，测试里不要写死某一种分隔符，尤其是快照测试和 CLI 输出。

第四，命令行参数和路径要分开处理。Windows 下反斜杠还会和转义字符纠缠，字符串字面量、shell quoting、JSON 配置都可能踩坑。路径问题看起来小，但它经常暴露一个项目是否真的尊重跨平台边界。

一个字符背后的工程教训

反斜杠的故事不是“谁当年选错了字符”，而是一次兼容性交易被长期放大的结果。短期里，它保护了旧程序；长期里，它把跨平台成本留给了一代又一代开发者。

这也是今天做平台设计时最该警惕的地方：早期语法、默认值、文件格式、命令参数看起来很小，一旦被生态采用，就会变成几十年都不敢轻易移动的地基。