似乎每次对站点中的某些文件进行更改时，我发现的所有静态站点生成器都会完全重新生成整个站点。
例如，使用中比较流行的站点生成器之一是 Jekyll，它为 Github Pages 提供支持。每当作者进行更改（例如在 post 文件中进行语法更正，或更改 about.html 布局）并需要重新生成该内容时，Jekyll 就别无选择，只能重新生成整个站点，即使有数百个文件，其输出未因最近的编辑而改变。
重新生成大型站点所需的时间似乎是对大多数静态站点生成器的常见抱怨。
是否有任何技术原因（来自静态站点生成器的开发或工程的 POV）阻止某人编写静态站点生成器，该生成器对其内容“智能”并且可以自我意识到可以理解哪些文件的程度已更改，哪些文件依赖于它（反之亦然）并且只会重新生成必要的文件？
由于大多数人（尤其是 Jekyll/GH Pages）用户都将他们的站点存储在 git 存储库中，因此站点生成器甚至可以利用提交信息并跟踪更改并依靠该信息来了解哪些文件需要重新生成和可以单独放置。想法？
简短的回答：这很难。
困难的部分是不知道哪些文件发生了变化。困难的部分是知道哪些输出文件受到更改的文件的影响。例如，如果您更改博客文章的标题，则需要更新主博客索引。任何标签页也是如此。任何将其他帖子列为“相关帖子”的页面也是如此。如果您的主页上有摘录，同样的交易。
但这也不是不可能处理的。您可以保留一个有向无环图来跟踪任何给定页面的依赖关系，并重新生成包含其他页面发生变化的位的页面。它增加了开销和代码复杂性，以及计算时间，但这样做可能是值得的。
然而，比这更难的是知道哪些页面需要重新生成，因为它们尚未关联的项目发生更改。如果您在博客文章中添加新标签会发生什么？现在，该新标签的标签页也需要重新生成。如果您使用标签来生成“相关帖子”，则应重新生成您网站上的所有帖子，因为任何给定帖子的“最佳”关系现在可能会有所不同。添加新帖子时会发生什么？为了避免不必要的编译，静态站点生成器必须知道如果该帖子存在，哪些页面会包含该帖子，并重新生成它们。
请注意，在所有这些情况下，误报（未更改但无论如何都重新编译的页面）是可以接受的，但误报（应该重新编译但不重新编译的页面）是绝对不可接受的。因此，在每种情况下，站点生成器都必须谨慎行事：如果再次编译页面可能会发生变化，则必须重新编译。
例如，Nanoc 确实会跟踪您提到的更改。它保留依赖于其他页面的页面的有向无环图，并在编译之间缓存它以限制重新编译的次数。它不会每次都重新生成每个页面，但它确实经常重新编译一些不需要编译的页面。还有很大的提升空间。