Windows 反斜杠不是历史八卦，而是平台兼容性的长期账单

Windows 反斜杠真正有意思的地方，不是“微软为什么不用正斜杠”，而是一个平台如何被自己的早期兼容承诺锁住。DOS 2.0 做子目录时，技术上可以向 Unix 靠拢；商业上却不能让 DOS 1.x 的命令和程序大面积断掉。

所以反斜杠不是一个孤立字符，而是平台治理的早期案例：当用户规模、合作伙伴和第三方软件已经形成惯性，最合理的工程决策未必是最干净的设计。

兼容性会把临时方案变成制度

很多技术债不是因为工程师不知道更优解，而是因为更优解出现得太晚。DOS 1.x 已经把正斜杠放进命令选项语法里，等目录层级需求出现时，正斜杠不再是空白字符。反斜杠于是成为兼容性的妥协。

这种妥协一旦被写进教程、脚本、企业系统和开发者肌肉记忆，就会从临时选择变成制度。后来的 Windows 可以兼容更多写法，却很难把默认文化整体迁走。

平台最贵的成本是外部迁移成本

一个操作系统内部改代码当然难，但更难的是让世界跟着改。批处理脚本、安装包、构建工具、CI 配置、注册表路径、文档示例、培训材料，全都属于外部迁移成本。平台越成功，外部迁移成本越大。

这解释了为什么很多“明显不优雅”的历史设计会活得很久。它们不是因为好，而是因为已经太多东西依赖它们继续保持原样。

给今天工具设计的提醒

如果你在设计 CLI、配置文件、插件协议或 Agent Skill 格式，早期默认值要非常克制。参数前缀、路径约定、命名空间、状态文件位置，一旦公开出去，就不再只是内部实现。

更安全的策略是：留扩展位，避免把通用字符过早占死；把用户输入和机器格式分开；给未来迁移留别名、版本字段和兼容窗口。

跨平台工程不要依赖“看起来能跑”

Windows 能在很多地方接受正斜杠，但这不代表项目可以忽略路径抽象。真正可靠的跨平台代码应该把路径交给标准库，把 URL、shell 参数和文件路径作为三种不同数据处理。