Hugo 如何维护站点范围的数据，例如 .Site.AllPages？答案

【问题标题】：How does Hugo maintain site-wide data, like .Site.AllPages?Hugo 如何维护站点范围的数据，例如 .Site.AllPages？
【发布时间】：2017-07-26 17:31:16
【问题描述】：

我正在寻找一些关于 Hugo 可能如何管理站点范围数据的简短示例，例如 Site.AllPages。

具体来说，Hugo 似乎太快无法读取每个文件及其元数据，然后才开始生成页面并使 .Site.AllPages 等内容可用 - 但显然一定是这样。

Ruby (Jekyll) 和 Python (Pelican) 真的那么慢吗，或者 Hugo 是否使用某种特定的（算法）方法在一切就绪之前生成页面？

【问题讨论】：

可能是the source?
Ruby 和 Python 比它们的支持者希望你相信的要慢得多。
@captncraig 也许我还是 Go 新手，在花了不少于 30 分钟挖掘 Hugo 项目之后，我不知道该去哪里找文件已经。鉴于您可能是一个友善、乐于助人的人，您的评论的措辞和简短长度不会以这种方式出现。请对未来的潜在菜鸟保持温和。

标签： go hugo

【解决方案1】：

没有魔法，直到 .Site.Pages 等集合被填充并准备好，Hugo 才开始任何渲染。

这里的一些关键点：

我们有一个处理管道，我们会在其中尽可能进行并发处理，因此您的 CPU 应该非常繁忙。
每当我们进行内容操作（简码、表情符号等）时，您很可能会看到为提高速度而构建的手工解析器或替换功能。
我们非常关心“快速”部分，因此我们有一套可靠的基准来揭示任何性能回归。
Hugo 是使用 Go 构建的——速度非常快，并且为此提供了一套非常棒的工具（pprof、基准测试支持等）

使hugo server 变体比常规hugo 构建更快的其他几点：

Hugo 使用虚拟文件系统，我们在服务器/开发模式下直接渲染到内存。
我们有一些部分重新加载逻辑。因此，即使我们每次都渲染所有内容，我们也会尝试仅重新加载和重建已更改的内容文件，如果是内容更改等，我们不会重新加载/重建模板。

我是 GitHub 上的 bep，Hugo 的主要开发者。

【讨论】：

很好的答案。 +1。我试图用我的回答回到 Site.page 的起源，但你的回答更具体。
@bep 非常感谢您花时间回答。我对 Go 还比较陌生，对 Hugo 的内部结构非常好奇。那么，将所有内容/元数据读入某种结构并（保存在内存中？）然后并发任务开始构建页面，这不是过于简单了吗？
大部分数据在渲染开始时都在内存中（我们对从模板访问的内容进行了大量的延迟加载/延迟生成 - 即我们不需要计算每个内容文件，如果模板中从未使用过该值），但简化后，您可以将其视为：文件读取和处理（并发）-站点组装等（串行，即一个 Go 例程）-渲染（并发）

【解决方案2】：

你可以看到AllPages in hugolib/page_collections.go。

git blame 表明它在Sept. 2016 for Hugo v0.18 in commit 698b994 中被修改，以修复PR 2297 Fix Node vs Page。

该公关引用discussion/improvement proposal "Node improvements"

一旦我们同意一个页面只是一个......页面......

而且节点只是一个带有鉴别器的页面。

所以：

今天的页面是带有鉴别器“页面”的页面

主页是带有“主页”或其他标识符的页面

分类法是带有鉴别器“分类法”的页面

...

它们有一些结构差异（分页等），但它们基本上只是页面。

考虑到这一点，我们可以将它们全部放在一个集合中，并在鉴别器上添加查询过滤器：

.Site.Pages: 过滤器 = 'page'
*.Site.All: 无过滤器

where: 当序列为 Pages 时添加 discriminator = 'page'，但让用户覆盖

该键（鉴别器）允许快速检索所有“页面”。

【讨论】：

非常感谢您抽出宝贵时间回答细节、清晰、指出问题所在等。非常有用的回答方式。