文件系统的组织已经帮我们将用户站点项目按Hugo基础组件的结构进行了组织。 我们从BaseFs.Content.Fs可以直接获取站点内容的文件系统索引，可以直接读取文件信息，生成站点面面了。

但Hugo不这么认为，我们可以用下面两个场景来了解一下Hugo的鸿鹄之志。

场景一：Headless Bundle

有一种页面，我们不希望她单独作为一个页面来发布。 但可以在需要她的时候，以变量的形式获取到她。 这就是Hugo对这种需求提供的解决方案： Headless Bundle。

如果直接遍历文件系统，我们在处理该文件的时候，需要知道她的类型，如果是Headless类型的，就不按常规类型处理。 那文件类型就需要在解析文件的时候，从文件信息中获取到。 页面类型的信息可以放在文件配置中，也可以通过特殊的命名规则来表明，此类方案还有许多。

如果其它的页面依赖于Headless页面，就要考虑页面解析顺序所带来的问题。 如果Headless在前面被解析，就要存储好相关索引信息，以方便后续依赖于她的文件进行查询。 如果在其它页面之后解析，可能的方案是将之前处理的页面标记为未完成状态，并指明所依赖的Headless页面，并挂起等待条件成熟时被唤醒。 等相应的Headless页面解析完成后，时机成熟时，恢复之前页面的解析流程。 这种方案在依赖的Headless页面较多的情况下，会出现不断挂起的状况。 加上这些配置都依赖于手工维护，解析效率和正确性都很难保障。

场景二：Page Resources

Hugo Page可以包含不同的资源，常见的有图片类型的，还有音频、视频、数据、压缩包等等多种类型的资源。

下载页面会提供资源的下载链接，比如软件的安装包，针对不同的操作系统，会提供不同的版本。 Hugo可以很聪明的识别，哪个文件是页面文件，哪些页面是资源文件，并将资源文件信息放在页面的Resources属性里。 这样就方便用户根据页面，来灵活组织这些资源，可以生成一个某一类型软件的下载汇总信息，还可以生成某一章节的下载软件信息。

如果直接遍历文件系统，每个文件都是相对独立的，需要通过配置信息或者其它的方式标明同一层级的从属关系，还要标明不同层级之间的引用关系。 这些都需要在全局构建信息中存储。 因为互相独立，遍历过程中又会有先后顺序，关系越复杂，重复信息出现的概率就会越高。 当有新的需求出现时，复杂的逻辑处理也不利于软件的拓展。

从以上两个场景中，可以观察到。 简单的遍历文件系统，确实可以获取基本的文件信息。 但如果需要灵活地组织各种不同的信息，如依赖关系，资源汇总等等跨页面处理场景，我们还需要进一步对站点内容进行发掘，以页面为单位进行组织和管理。

磨刀不误砍柴工#

从 Hugo事件风暴中可以清楚的看到Hugo正式收集站点内容是在Hugo Build阶段，之前都是在做准备：

分工明确，高效协作#

电商现在的状态已然不是正在融入我们的生活，而是成为了我们生活的一部分。 并且过了拼产品类目的时期，基本上你家有的，我这也有。 现在拼的更多的是特色，和服务。 既然是特色，那每家多多少少都有些不一样。 而服务，基本上都是相同的，其中最重要的要属快递服务。 谁能以最短的时间将包裹送达消费者手中，谁将最容易获得消费者的认可，从而占有更高的市场份额，获得投资者的青睐，进入良性的循环发展。

Hugo也认同最短时间送达这样的服务理念。 拿到待处理的内容后，立马出库装车送到离消费者最近的分拣中心，再由高效的分类机器人对货品进行分类。

Hugo对内容处理的目标

在我们的样例中，我们的Content就是mycontent目录所代表的文件系统，经过PathSpec处理后，文件系统可通过site.BaseFs.Content.Fs得到。 最终，Hugo需要对内容文件系统中的所有内容进行分类，并存放在PageMap货架上，这样方便快递小哥快速取货，装车并将包裹送达用户手中。

那Hugo到底是怎么做到的呢？

陆地集装箱 – 大卡车

在实际生活中，包裹会从全球各地通过分拣中心网络，靠大卡车运输到离消费者最近的分拣点。 而Hugo的"大卡车"就是PagesCollector，不像现实世界那么复杂，货物都在site.BaseFs.Content.Fs中。

分拣机器人

等货物运到分拣中心后，经过不断对分拣效率进行优化，现在已经做到可以完全自动化。 PagesController将所有文件送达后，自动分拣机器人PagesProcessor便开始工作，无缝衔接。 为了提高处理效率，Hugo为每一个站点都提供了一个机器人，由PagesProcessor负责分发任务，sitePagesProcessor专注处理自己所擅长的语言类别。

通过明确的分工，高效的协作，最终将所有文件分门别类，规整的放在中心货架上。