09。Hugo架构站点内容的收集方案

　　文件系统的组织已经帮我们将用户站点项目按Hugo基础组件的结构进行了组织。我们从BaseFs。Content。Fs可以直接获取站点内容的文件系统索引，可以直接读取文件信息，生成站点面面了。
　　但Hugo不这么认为，我们可以用下面两个场景来了解一下Hugo的鸿鹄之志。
　　场景一：HeadlessBundle
　　有一种页面，我们不希望她单独作为一个页面来发布。但可以在需要她的时候，以变量的形式获取到她。这就是Hugo对这种需求提供的解决方案：HeadlessBundle。
　　如果直接遍历文件系统，我们在处理该文件的时候，需要知道她的类型，如果是Headless类型的，就不按常规类型处理。那文件类型就需要在解析文件的时候，从文件信息中获取到。页面类型的信息可以放在文件配置中，也可以通过特殊的命名规则来表明，此类方案还有许多。
　　如果其它的页面依赖于Headless页面，就要考虑页面解析顺序所带来的问题。如果Headless在前面被解析，就要存储好相关索引信息，以方便后续依赖于她的文件进行查询。如果在其它页面之后解析，可能的方案是将之前处理的页面标记为未完成状态，并指明所依赖的Headless页面，并挂起等待条件成熟时被唤醒。等相应的Headless页面解析完成后，时机成熟时，恢复之前页面的解析流程。这种方案在依赖的Headless页面较多的情况下，会出现不断挂起的状况。加上这些配置都依赖于手工维护，解析效率和正确性都很难保障。
　　场景二：PageResources
　　HugoPage可以包含不同的资源，常见的有图片类型的，还有音频、视频、数据、压缩包等等多种类型的资源。
　　下载页面会提供资源的下载链接，比如软件的安装包，针对不同的操作系统，会提供不同的版本。Hugo可以很聪明的识别，哪个文件是页面文件，哪些页面是资源文件，并将资源文件信息放在页面的Resources属性里。这样就方便用户根据页面，来灵活组织这些资源，可以生成一个某一类型软件的下载汇总信息，还可以生成某一章节的下载软件信息。
　　如果直接遍历文件系统，每个文件都是相对独立的，需要通过配置信息或者其它的方式标明同一层级的从属关系，还要标明不同层级之间的引用关系。这些都需要在全局构建信息中存储。因为互相独立，遍历过程中又会有先后顺序，关系越复杂，重复信息出现的概率就会越高。当有新的需求出现时，复杂的逻辑处理也不利于软件的拓展。
　　从以上两个场景中，可以观察到。简单的遍历文件系统，确实可以获取基本的文件信息。但如果需要灵活地组织各种不同的信息，如依赖关系，资源汇总等等跨页面处理场景，我们还需要进一步对站点内容进行发掘，以页面为单位进行组织和管理。磨刀不误砍柴工
　　从Hugo事件风暴中可以清楚的看到Hugo正式收集站点内容是在HugoBuild阶段，之前都是在做准备：
　　分工明确，高效协作
　　电商现在的状态已然不是正在融入我们的生活，而是成为了我们生活的一部分。并且过了拼产品类目的时期，基本上你家有的，我这也有。现在拼的更多的是特色，和服务。既然是特色，那每家多多少少都有些不一样。而服务，基本上都是相同的，其中最重要的要属快递服务。谁能以最短的时间将包裹送达消费者手中，谁将最容易获得消费者的认可，从而占有更高的市场份额，获得投资者的青睐，进入良性的循环发展。
　　Hugo也认同最短时间送达这样的服务理念。拿到待处理的内容后，立马出库装车送到离消费者最近的分拣中心，再由高效的分类机器人对货品进行分类。
　　Hugo对内容处理的目标
　　在我们的样例中，我们的Content就是mycontent目录所代表的文件系统，经过PathSpec处理后，文件系统可通过site。BaseFs。Content。Fs得到。最终，Hugo需要对内容文件系统中的所有内容进行分类，并存放在PageMap货架上，这样方便快递小哥快速取货，装车并将包裹送达用户手中。
　　那Hugo到底是怎么做到的呢？
　　陆地集装箱大卡车
　　在实际生活中，包裹会从全球各地通过分拣中心网络，靠大卡车运输到离消费者最近的分拣点。而Hugo的大卡车就是PagesCollector，不像现实世界那么复杂，货物都在site。BaseFs。Content。Fs中。
　　分拣机器人
　　等货物运到分拣中心后，经过不断对分拣效率进行优化，现在已经做到可以完全自动化。PagesController将所有文件送达后，自动分拣机器人PagesProcessor便开始工作，无缝衔接。为了提高处理效率，Hugo为每一个站点都提供了一个机器人，由PagesProcessor负责分发任务，sitePagesProcessor专注处理自己所擅长的语言类别。
　　通过明确的分工，高效的协作，最终将所有文件分门别类，规整的放在中心货架上。