macOS 路径分隔符的双重变奏：一场跨越三十年的技术妥协

背景

在 Unix 和 Linux 生态系统中，正斜杠（/）作为目录分隔符是理所当然的标准，而文件名中包含斜杠通常是被禁止的，因为它会破坏路径解析逻辑。相比之下，Windows 使用反斜杠（\）。然而，macOS 却呈现出一种令人困惑的“精神分裂”状态：用户可以在 Finder（访达）中轻松创建文件名包含正斜杠的文件或文件夹，但在终端中查看时，这些斜杠却变成了冒号（:）。

这种现象并非 bug，而是 macOS 历史架构遗留的直接结果。它反映了现代 macOS 内核中两种截然不同的文件系统哲学——源自经典 Mac OS 的 HFS+ 和源自 Unix-like 系统的 NeXTSTEP——在融合过程中产生的兼容性层。

核心内容

1. 现象：Finder 与终端的视角差异

作者回忆道，macOS 允许用户创建看似包含斜杠的文件名。例如，在 Finder 中创建一个名为 a:b:c 的文件夹或 x:y:z.txt 的文件，系统会正常显示。然而，如果在终端运行 ls 命令，你会看到完全不同的景象：

$ ls
a:b:c/ x:y:z.txt

这里的关键在于，文件名中实际上包含的是冒号，而不是斜杠。这种视觉上的差异源于 macOS 内部存在两套路径分隔符：正斜杠（/） 和 冒号（:）。系统会在不同语境下自动在这两者之间进行转换。

2. 历史根源：经典 Mac OS 与 NeXTSTEP 的融合

现代 macOS 是两大技术体系的结合体：

• 经典 Mac OS：使用 HFS+（Mac OS Extended File System）文件系统，其路径分隔符为冒号（:）。
• NeXTSTEP（macOS 内核的基础）：使用 UFS（Unix File System）等 Unix 类文件系统，其路径分隔符为正斜杠（/）。

当 Apple 将这两者结合时，工程师们必须构建一个兼容层。2000 年 Usenix 会议上，几位 Apple 工程师发表了一篇论文，详细描述了这一融合过程中的挑战。论文中指出，这种翻译层在极少数情况下会导致“用户可见的精神分裂”：

包含冒号字符的文件名，在 Carbon 应用程序中显示为正斜杠，而在 BSD 程序和 Cocoa 应用程序中则显示为冒号。

这意味着，不同的 API 和应用程序接口（API）对同一文件名的解析方式不同，导致了用户看到的界面与底层存储结构之间的差异。

3. AppleScript 中的历史遗留

在现代 macOS 中，最可能遇到冒号作为路径分隔符的场景是 AppleScript。由于 AppleScript 的历史可以追溯到 System 7，当时它只需要关心 HFS+ 和冒号分隔符。

例如，使用 osascript 获取当前脚本的路径：

$ which osascript
/usr/bin/osascript
$ osascript -e 'tell application "Finder" to get (path to me)'
alias Phoenix SSD:usr:bin:osascript

这里返回的是经典的 HFS 风格路径（SSD:usr:bin:osascript）。如果需要获取 Unix/POSIX 风格的路径，必须显式请求：

$ osascript -e 'tell application "Finder" to get POSIX path of (path to me)'
/usr/bin/osascript

4. APFS 时代的延续

2017 年，Apple 用 APFS（Apple File System）取代了 HFS+。尽管底层文件系统已经更新，但双路径分隔符的机制依然保留。虽然 Apple 官方文档中难以找到明确确认这一点的依据，但普遍认为是出于向后兼容性的考虑。如果强行统一为单一的分隔符，将会破坏大量依赖旧有行为的历史软件。

5. 认知偏差：Unix 霸权下的“怪异”

作者指出，这种“文件名中包含斜杠”的现象之所以让人“大脑宕机”，是因为许多开发者是在 Unix 风格文件系统占据主导地位之后才开始编程的。在他们的认知中，斜杠是目录分隔符，而文件名中包含斜杠是非法的。

事实上，文件系统历史上曾使用过多种目录分隔符。Unix 当前的霸权地位使得其他分隔符显得“怪异”。在另一条时间线上，文件名中包含正斜杠可能被视为完全正常的事情。

关键要点

• 双分隔符机制：macOS 内部同时存在正斜杠（/，源自 Unix）和冒号（:，源自经典 Mac OS）作为路径分隔符，系统会在不同语境下自动转换。
• 视觉差异：Finder 等现代 GUI 应用倾向于显示 Unix 风格（正斜杠），而底层 BSD 工具或 AppleScript 可能显示经典 Mac 风格（冒号）。
• 历史兼容性：这种机制是经典 Mac OS（HFS+）与 NeXTSTEP（Unix）融合时的产物，旨在确保旧软件在新系统上的正常运行。
• AppleScript 的典型性：AppleScript 保留了大量经典 Mac OS 的习惯，默认返回冒号分隔的路径，需显式请求 POSIX path 才能获得 Unix 风格路径。
• APFS 未改变现状：即使底层文件系统已升级为 APFS，双分隔符机制仍因向后兼容性而保留。
• 认知相对性：文件名中允许斜杠并非 macOS 独有的“怪异”，而是 Unix 霸权下开发者产生的认知偏差；历史上文件系统分隔符多样，并无绝对标准。

意义与影响

1. 向后兼容性的代价与必要性

macOS 保留双路径分隔符是软件工程史上“向后兼容性”优先于“设计纯洁性”的典型案例。尽管这给开发者带来了认知负担和潜在的边界情况（edge cases），但它确保了从 System 7 到 macOS 15 的庞大软件生态得以平滑过渡。如果 Apple 在引入 APFS 时强行移除冒号分隔符，将导致无数依赖 HFS 路径格式的历史脚本、配置文件和应用程序崩溃。

2. 对开发者的启示

对于 macOS 开发者而言，理解这一机制至关重要：

• 路径处理需谨慎：在处理文件路径时，不应假设分隔符始终是 /。特别是在调用 AppleScript 或与旧版 Carbon 应用交互时，需警惕路径格式的转换。
• API 选择：优先使用 POSIX 路径（/）进行跨平台开发，除非明确需要与经典 Mac 组件交互。
• 调试技巧：当遇到文件名显示异常或路径解析错误时，检查 ls 输出与 Finder 显示的差异，有助于判断是路径编码问题还是 API 兼容性问题。

3. 技术演进的哲学反思

这篇文章提醒我们，操作系统并非凭空设计的理想产物，而是历史包袱与技术演进的混合体。macOS 的“精神分裂”路径分隔符，是 Apple 在保持创新（引入 Unix 内核）与尊重用户习惯（保留经典 Mac 体验）之间做出的艰难平衡。这种平衡虽然带来了复杂性，但也体现了大型软件系统在长期演进中维持稳定性的智慧。

最终，所谓“怪异”往往只是视角的差异。在 Unix 主导的今天，macOS 的冒号分隔符显得格格不入；但在经典 Mac OS 的时代，冒号才是自然的选择。理解这一点，有助于我们更包容地看待技术历史中的“不完美”设计。