一、应用
写这篇文章的时候我想起来的是之前看到的一段轶事。具体的文字已经不可考，但大致如下：
在一节计算机课堂上，教授跟学生说：「请大家打开 C 盘下的 xxx 文件。」这时有学生问道：「教授，请问我要用哪个 App 来做到这件事？」后来教授惊讶地发现，这一代的学生有些从来没有接触过文件管理器这个概念。他们从小到大接触到的都是一个个的 App，以及 App 内一个个具象的视频、音乐、文档等。对于他们来说，文件及文件夹是一个陌生的概念。
这一现象是什么时候开始的？或许有些人会认为是 iPhone 的诞生作为开端，但我更倾向与认为是 2004 年 Gmail 的诞生引领了这一趋势。
2004 年的愚人节，Google 正式发布了第一个版本的 Gmail，并宣布提供给每个用户 1GB 的存储空间。这在当年是非常具有轰动性的产品。在那之前，用户使用邮箱是通过客户端（Outlook 或者 Thunderbird）把邮件下载到本地后使用。因为当年邮箱提供商给予用户的免费空间一般按 MB 来计算，因此 Gmail 的推出一下子引发大量用户的迁移。
或许有很多人对 2004 年这一概念感到模糊，但我印象还算比较深。因为 2004 年正是我家刚买入第一台个人电脑的那年。当年我们家选配的硬盘为 80GB。
可能你会疑惑，只是增大免费容量为什么会作为一个趋势的起点？在我看来，这带来了用户使用习惯的改变。前文提到，在那之前用户使用邮箱是需要把邮件下载到本地后处理，因为邮箱提供商分配的空间有限，这意味着邮件的处理都是发生在本地的行为。邮箱提供商主要的服务仅仅在于发送与接收。但是当存储空间提升后，用户为什么还要将邮件下载到本地后处理呢？用户可不可以直接在网页上处理呢？事实上，当时已经有人这么做了。
注意，在以上的描述中我还没引入云的概念。对于大多数用户来说，最先让用户意识到云这一概念的产品是 iCloud。但在这之前还有一项划时代的产品需要介绍。同样出自 Google 之手，那便是今天大多数人的浏览器 — Google Chrome 的内核 Chromium。
二、基础设施
今天，除了苹果的 Safari 和 Mozilla 的 Firefox，大多数现代浏览器都是以 Chromium 为内核的应用。在当年，IE6 已经很久没有人维护了，网页技术的发展停滞不前。Chrome 的推出迅速刺激了沉寂已久的技术发展，人们意识到原来浏览器可以如此的快。注意，这里的快不仅是网页加载得快，而是在网页上做出复杂操作的时候响应速度的快。
同时，Chrome 也将 Web App 这一概念第一次让广大用户认知。但 Web App 这一概念并非由 Google 提出，
让我们把时间再往前几年，1995 年 Netscape 推出了 Javascript 编程语言。这一编程语言允许浏览器在网页上进行动态处理。2007 年，在 Chrome 推出的一年前，Mozilla 便推出了一个项目 — Mozilla Prism。Prism 将 Web App 和桌面操作系统深度整合，用户可以在桌面上直接打开某个 Web App。与在桌面建立某个网页书签不同，Prism 允许用户针对不同的网页配置不同的偏好设置。
以上一项为技术基础，一项更偏向理念，Google 在推出 Chrome 的时候便充分受益于此。在 Chrome 发布前夕，Google Blogoscoped 的作者 Philipp Lenssen 便将 Chrome 的主要特性总结为
以下几点：
- Chrome 是 Google 的开源浏览器项目（编者注：此处说法有误，Chromium 才是开源的项目）
- Chrome 会包含一个新的 Javascript 引擎叫 V8
在我看来，以上特性中，真正具有革命性的功能为 V8 引擎以及将 Web App 的概念在浏览器设计之初便作为其重要特性。前者是后者的技术基础，而后者是消灭文件的基础。
三、云
2011 年，随着 iOS 5 一起发布的还有 iCloud 服务。至此，所有的拼图都完成了。iCloud 类的远程存储让广大用户意识到数据存储在本地不一定是安全的。这里的安全并不是私密性上的安全，而是能极大地降低数据丢失的风险。同时，只要网络条件允许，用户可以在任何物理设备上访问到自己的数据。换言之，本地存储不再是唯一选项。甚至随着网速的提升及网络延迟的降低，除了数据敏感性高的内容外，一切数据都可以放在云端。
但 iCloud 并不是第一个做云端硬盘的公司，早在 2005 年，Aaron Levie 就发布了 Box.net 这一云端硬盘产品。它允许用户将自己的文件放置于网盘上，并且可以像在本地文件一样管理。更先进的产品是 2008 年发布的 Dropbox，与 Box.net 一样提供云端硬盘服务。不同的是它提供了增量同步功能。这意味着如果用户对一个文件进行修改，Dropbox 可以做到只同步修改的部分。
从技术上看，Dropbox 将用户的文件拆分为许多小块，并将这些小块的属性计算出一个数值。我们只需要知道如果某一小块的数据有变更，那么这一小块的数值便会改变。通过对比本地和云端的数值便可以决定需要同步本地及云端的哪些内容。
增量同步除了提高同步速度外，还意味着文件存储形式的改变。用户的文件不再是原来的文件，而是被拆分成一段段数据，通过后期的拼接组合成用户原来的文件。虽然文件在本地硬盘的存储方式也是类似，但与本地存储不同，云端硬盘可以将用户文件拆分出来的一段段数据分散存储在不同的硬盘，甚至不同的数据中心。这一特性还有什么应用我们在此按下不表，后面会讲到。
iCloud 更为激进，在刚开始发布时它直接屏蔽了用户访问具体文件的选项。与 iOS 类似，用户使用 iCloud 是通过一个个 App 来实现。iCloud 和系统的整合更深，用户无法感知文件的存储及同步过程，本地存储和云端存储的边界更模糊了。用乔布斯的话来说就是 It Just Works。
但在这一步走得更远的依旧不是苹果。作为一家卖硬件为主要利润的公司，iCloud 主要的服务对象依然是苹果用户。对于其他操作系统，iCloud 显得过于封闭。而打破这一局面的仍然是 Google。在 iCloud 发布一年后，Google 也推出了自己的云端网盘 Google Drive。一开始发布时我以为这是一款比上不足比下有余的产品。它没有 Dropbox 的增量同步，也没有 iCloud 那般与操作系统深度整合的能力。似乎是一款可有可无的产品。但经过这些年发展，我发现它走的是另一条路，一条真正杀死用户文件的路。
四、文件的消逝
让我们暂且把目光转向更娱乐的地方 — 音乐。
我还记得以前听音乐的流程。在酷狗音乐上搜索自己喜欢的作品，然后点击下载。通过酷狗或者其他播放器打开刚才下载的 mp3 文件收听。有些音乐在各大音乐平台找不到，便到百度搜索，通过 BT 或者网盘下载到本地并整理好文件的元数据（歌手、专辑等）。在整理好后，将一些最近比较火的音乐整理好传到 MP3 里听。
后来我发现了豆瓣 FM。豆瓣 FM 和酷狗音乐最大的区别在于，豆瓣 FM 是纯流媒体的模式，即我们没法下载单曲，而只能在网页上播放。与之带来的变化是，我不再与一个个 mp3 文件打交道，将其手动整理好存到电脑里。甚至我不再需要下载程序，只需要登上豆瓣 FM 的网页就能开始听音乐。另外在存储空间不再是掣肘后，收听的音乐种类大大拓宽。通过不同的电台，我可以听到许多未曾接触的音乐。
这便是流媒体。
在今天这显得非常普遍，我们在 Netflix 上看电影，在 Spotify 上听音乐。理想情况下，我们不再需要下载这些内容，甚至下载这一概念已经变得陌生，取而代之的是离线观看（收听）。用户不再需要跟文件打交道，服务商也可以将这些内容用 DRM 锁定防止盗版，并更激进地使用私有协议。比如苹果通过 Apple Music 推出 Spatial Audio，在以往是很难实现的。
同时得益于流媒体的发展，获取新内容的成本大大降低。因为大多数流媒体都是按月收费，即用户付出一定的成本后，获取新内容的边际成本几乎为 0。这便带来了更多长尾内容。以往一个创作者创作出一张专辑，要说服未曾听过的人购买是很难的。但当获取新内容的边际成本降低为 0 后，用户消费新内容的门槛更低了，独立创作者的内容也更容易被消费到。
用户失去了文件的所有权，但也换来了更蓬勃的生态，以及更方便的使用体验。
这不仅发生在内容消费领域，在内容生产领域也略显端倪。
以文档处理为例，以往文档处理工具便是 Microsoft Office 三件套。诚然，Office 三件套功能十分强大，但它一开始的设计并没有考虑到云时代，所有文档的操作都是基于单一文件。而 Google Docs 则完全建立在云时代的基础上，也正是得益于这一后发优势，Google Docs 从设计之初就考虑到团队协作。也正是对用户屏蔽了文件这一形式，在线协作才成为可能，因为单一文件在修改的时候总是具有排他性的。
事实上，Google Docs 的文档会在 Google Drive 上显示出来，但如果我们将其下载下来会发现，这个文件只是一个链接。这也是我在前面提到的 Google Drive 设计的更先进之处 — 对于用户来说，文件并没有用，用户需要的是文件的应用。而与苹果的 iCloud 不同，Google Drive 真正做到了全平台。用户在本地不需要安装任何应用，在 Google Drive 上无数开发者提供了许多 Web App 让用户使用这些文件。与 Dropbox 不同的是，Google Drive 本身不实现增量同步，而是将这一工作下放给应用方实现。在线协作正是增量同步的体现。
Google Drive 的设计真正得益于前面三部分 — 应用、基础设施、云。通过应用（Google Docs）随时随地在基础设施（Google Chrome）上打开云（Google Drive）上的数据生产或消费。Google Drive 并不是传统的网盘，它更像是一个入口。
不止 Google，如今许多其他的应用也如雨后春笋般出现。比如 Figma，在 2016 年推出后迅速成为设计师最爱的生产力工具。比如 Notion，几乎只需要维护一份代码便可以提供全平台应用。
上述两个应用在创立之初都摒弃了传统文件的概念，比如在 Figma 里，我们不需要关心一个项目的所有 Page 是否是同一个文件。也正得益于屏蔽文件的设计，协作办公可以非常自然地实现。设计师和产品经理不再需要传输一个个 Sketch 文件，在某个有疑问的地方圈圈点点地沟通，而是直接在设计的过程中添加注释（改需求）。
即便是对文件系统最熟悉的程序员也逐步有屏蔽文件系统的趋势。在 Golang 里，外部依赖包是通过包的自定义地址引入。比如我要引用 MySQL 包，只需要在引入里写上 github.com/go-sql-driver/mysql 即可。在未来，Golang 是否还需要将外部包下载到本地再使用呢？进一步来推进，是否可以有一款新的编程工具如 Figma 那样，用户不再需要像现在一样整理文件的编排，而是用类似 Page 的形式整理，通过类似标签的形式引用别处的代码？
上述应用的发展都充分体现了一点：传统操作系统正在式微，而浏览器正在取代操作系统。事实上，Chrome 也推出了 ChromeOS 操作系统以及对应的 ChromeBook 笔记本。
目前这一替代还未成熟，对于计算密集型的应用还无法替代。比如音视频剪辑的应用还未成熟，虽然已经有产品正在尝试（比如 Dropbox Replay）。更难替代的是专业的工业软件。但对于大多数用户，文件确实已经消失了。尽管文件是操作系统最基本的单位，但用户并不需要知道这些。
登录
