文章探讨为何文件系统在现代软件中仍不可或缺

在个人计算的大部分历史中，文件和目录并不是隐藏在应用程序背后的东西。它们是你理解机器的一部分。 一份文档有名字，有存放的位置。那个位置在一个目录里，而目录本身又可能位于另一个目录之中。应用程序打开文件、保存文件、复制文件，有时还会创建自己的文件夹，但底层结构依然可见。 在现代软件中，这种模型已经变得不那么明显了。许多应用程序如今在内部管理自己的内容，通过云服务进行同步，呈现给用户的是笔记、项目、照片、对话或工作区，而不是文件和文件夹。 这确实很方便，但文件系统依然重要，因为它赋予信息一种独立于当前使用它的应用程序而存在的结构。 文件是计算中最基本的抽象之一。 操作系统为一批数据赋予名称和位置，以及所有权、权限、时间戳、大小等元数据。程序可以读取或修改这些数据，而不必理解底层的存储设备是如何工作的。 这种抽象极其成功，因为它在软件和操作系统之间建立了一份简单的契约。 文本编辑器不需要知道文件是在硬盘、SSD、网络共享还是可移动驱动器上。它只需请求操作系统打开文件。文件系统负责处理细节。 同样的抽象对用户也有帮助。我们可以用文档和目录来思考，而不是磁盘扇区和存储块。 这是一个好的抽象，因为它隐藏了复杂性，却没有隐藏信息本身的存在。 目录结构的作用不只是防止文件堆积在一个巨大的列表里。 一个名为 2026 的文件夹里放着一个名为 Taxes 的文件夹，在任何应用程序打开这些文件之前，就已经传达了关于其中文件的一些信息。目录树可以表示项目、年份、客户、主题、机器、照片、源代码、研究资料，或者几乎任何其他东西。 这种结构是可见的，而且通常无需专门的软件就能理解。 这一点很重要，因为组织方式能够在应用程序更替后存续下来。 如果我有一个目录，里面装着 Markdown 文件、图片、PDF 和电子表格，我可以替换掉打开这些文件的应用程序，而不必改变信息本身的组织方式。目录树属于用户，而不是属于某一个程序。 这种分离很容易被低估。 普通文件最有力的论据之一，就是许多不同的程序可以处理同一份数据。 一张以 JPEG 存储的照片不属于照片查看器。一个文本文件不属于创建它的编辑器。一份 PDF 不会因为我卸载了平时用来阅读它的程序就不复存在。 这听起来显而易见，但并非所有现代软件都是这样运作的。 有些应用程序主要把信息当作自己系统内部的对象。一条笔记可能作为数据库中的一条记录存在。一个项目可能由散布在多个内部文件中的数据组成。一组照片可能通过某个应用程序管理的图库来表示，而不是通过用户通常能看到的目录。 这样做有充分的技术理由。在许多情况下，数据库处理元数据、关系、索引、同步、版本控制和搜索的效率，远高于一堆松散的普通文件。 代价是应用程序对数据变得更加重要。 很容易把这写成对现代软件隐藏一切的抱怨，但那样就会忽略应用程序管理内容为何变得普遍。 照片管理程序可能需要存储评分、人脸、编辑、相册、标签、位置以及同一张图片的多个版本。笔记应用可能支持笔记之间的链接、嵌入文件、同步、全文搜索和协作。音乐应用可能需要播放列表、专辑元数据、封面图和收听历史。 试图把所有这些都清晰地表示为一个可见的普通文件夹层级，可能会变得很别扭。 对应用程序来说，数据库方案可能好得多。 它也让用户体验更简单。用手机拍照的人不想先选择目录路径和文件名。有用的抽象通常是“我的照片”，而不是 /storage/DCIM/Camera/IMG_20261030_114522.jpg。 问题出在这种抽象成为触达信息的唯一可用方式之时。 好的软件会隐藏用户不必手动管理的细节。 我不需要知道一份文档在 SSD 上的物理块地址。我不想每次编辑笔记时都手动维护数据库索引。那些是实现细节。 但知道我的数据在哪里、我能否独立访问它，未必就是实现细节。 应用程序说“你不需要关心我内部如何组织这些内容”，和说“没有我你就无法有意义地访问这些内容”，两者之间有重要区别。 前者是抽象。后者是依赖。 应用程序可以在内部管理内容，同时仍然提供可靠的导出、标准格式、备份或对底层文件的直接访问。只要这些退路存在，这种抽象就没那么令人担忧。 当它们不存在时，用户的信息和应用程序就紧密耦合在一起了。 目录树还代表着可能在其他任何地方都不存在的知识。 假设我按项目、主题和日期组织了一个层级来维护研究资料。文件夹结构本身告诉我，我是如何决定这些材料之间关系的。 这种组织方式可能粗糙，也可能无法完美扩展，但它是持久的。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）