静态站点生成器简介
静态网站生成器最近似乎变得越来越流行，但它们并不是那些短暂的新奇事物，它们的流行程度很快，不久就会被遗忘。十多年来，许多不同的项目–更准确地说，是394个项目–一直由社区中许多不同的人维护，并使用不同的编程语言和技术来构建。
我经常在关于这个主题的文章中读到 “静态网站不适合所有人”，部分原因是缺乏管理内容的用户界面和有时不友好的安装过程。但实际上，我认为它们可以为每个人服务，只是不适合所有东西。
这篇文章的目的是帮助所有技能水平的人准确地理解什么是静态网站生成器，承认它们的优点，并理解它们的局限性是否是一个破坏者，或者相反，它们是否可以被克服。有了这些，你就有希望在静态网站是否能成为你下一个项目的解决方案上做出明智的决定。
整个文章所描述的概念对所有的静态网站生成器都是有效的，因为它们都有相同的理念，尽管我在写的时候会想到Jekyll，因为这是我使用的最有经验的一个。它是一个相当成熟的产品，有一个巨大的社区，并且有一个很大的好处，那就是被GitHub页面所支持。不过，Docpad、Hugo和Wintersmith等替代品也被广泛使用，绝对值得研究。
动态网站如何运作
试着想象一下，人们想知道世界上发生了什么，唯一的办法就是去附近的新闻亭，要求阅读最新的新闻。是的，我知道这很傻，但一会儿就会明白了，请忍耐一下。
服务员没有办法知道什么是最新消息，所以他把请求转给了一个满是电话接线员的密室–想象一下20世纪50年代的一个大电话总机室。当接线员有空时，他们会接受请求，给一长串的新闻机构打电话，询问最新的新闻，然后把结果写在一张纸上作为要点。
然后，接线员会把他的粗略笔记交给一个代写员，代写员会把最后的副本写到一张漂亮的纸上，按照一定的布局排列，并加上一些零碎的内容，如报亭的品牌和联系信息。最后，服务员拿着完成的纸张，把它送给快乐的顾客。然后，整个过程将对每一个到达信息亭的人重复进行。
这基本上就是一个动态网站的工作方式。当访问者来到一个网站（报刊亭），期待着最新的内容（新闻），一个服务器端的脚本（操作员）将查询一个或多个数据库（新闻机构）以获得内容，并将结果传递给一个模板引擎（潦草），后者将格式化并适当安排一切，并生成一个HTML文件（成品报纸）供用户使用。
静态网站如何工作
静态网站的主张是将沉重的负载从访问者请求内容的时刻转移到内容实际变化的时刻。回到我们的新闻亭的比喻，想想这样一个场景：每当有什么有价值的新闻发生时，都是由新闻机构来呼叫新闻亭。
然后，报刊亭的操作员和涂鸦者将对这些故事进行汇编、格式化和风格化，并立即制作一份成品报纸，尽管还没有人订购。他们将打印出大量的副本（实际上是无限的），并把它们堆放在店面旁边。
当顾客到来时，不需要等待接线员的空闲，打好电话，把结果传给涂鸦者，然后等待最终产品。报纸已经在那里，堆积如山地等待着，所以顾客可以立即得到服务。
而这就是静态网站生成器的工作方式。他们采取内容，通常存储在平面文件而不是数据库中，将其应用于布局或模板，并产生一个纯静态HTML文件的结构，准备交付给用户。
静态的优点
1) 速度
也许静态网站最容易被注意到的特点是它有多快。如上所述，没有数据库查询需要运行，没有模板制作，也没有对每一个请求进行任何处理。
网络服务器在快速提供静态网页方面非常出色，整个网站由静态的HTML文件组成，这些文件在服务器上，等待着被提供，所以一个请求几乎瞬间就被送回给用户。
2）内容的版本控制
你甚至无法想象在一个没有版本控制的项目上工作，是吗？在任何软件项目中，无论多小的项目，拥有一个人们可以协同工作的文件库，准确控制谁做什么，并在出错时回滚修改，都是必不可少的。 但内容呢？那是任何网站的基石，但它通常位于其他地方的数据库中，与代码库及其版本控制系统完全分离。在静态网站中，内容通常被存储在平面文件中，并被当作代码库的任何其他组件。以博客为例，这意味着可以将实际的文章存储在GitHub仓库中，并允许你的读者在有问题时提出问题，或通过拉动请求来添加修正，这有多酷啊？
3) 安全性
像WordPress这样的平台被全世界数以百万计的人使用，这意味着它们是黑客和恶意攻击的常见目标–这是没有办法的事。只要有用户输入/认证或多个进程在每个请求上运行代码，就有一个潜在的安全漏洞可以利用。为了应付这种情况，网站管理员需要不断地给他们的系统打安全更新补丁，不断地与攻击者玩猫捉老鼠的游戏，这种例行公事可能被经验不足的用户所忽视。
静态网站保持简单，因为只有一个提供普通HTML页面的网络服务器，就没有什么可搞的。
4) 服务器的问题更少
安装和维护运行动态网站所需的基础设施是相当具有挑战性的，特别是当涉及到多个服务器或需要迁移的时候。有不同版本和依赖性的包、库、模块和框架，有不同操作系统中的不同网络服务器和数据库引擎。
当然，静态网站生成器也是一个软件包，也有它的依赖性，但这只在网站生成时才有意义。最终，最终的结果是一个HTML文件的集合，可以在任何地方提供服务，根据需要进行扩展和迁移，而不管服务器端的技术如何。至于网站的生成过程，可以在你本地控制的环境中完成，而不一定是在运行网站的网络服务器上–嘿嘿，你可以在你的笔记本电脑上建立整个网站，并在完成后将结果推送到网络上。
5) 应对流量激增
网站上意外的流量高峰可能是一个问题，特别是当它高度依赖数据库调用或重度处理时。引入缓存层如Varnish或Memcached肯定有帮助，但这最终会在系统中引入更多可能的故障点。
静态网站通常对这些情况有更好的准备，因为提供静态HTML页面消耗的服务器资源非常少。
静态的缺点（和潜在的解决方案）
1）没有实时内容
有了静态网站，你就失去了拥有实时数据的能力，例如关于过去一小时哪些故事在流行的指示，或为每个访问者动态变化的内容，如 “为你推荐的文章 “之类的东西。静态就是静态，对每个人来说都是一样的。
这恐怕没有真正的解决方案。这是使用静态网站要付出的最终代价，所以你必须问自己一个问题：”我的网站需要有多大的实时性？” - 如果它的概念是围绕着提供实时信息，那么也许静态网站并不是正确的选择。
一个危险的解决方案。当你面临在静态网站上动态更新内容的挑战时，有一个简单的出口。”我可以用JavaScript来做”。在客户端进行处理，并在提供服务后将结果附加到页面上，这对某些情况来说是正确的方法，但绝不能将其视为将静态网站变成完全动态网站的神奇解决方案。它可能会阻止一些用户看到注入的内容，损害你的搜索引擎，并引入其他问题，有可能夺走使用静态网站带来的轻松和控制感。
2）没有用户输入
在静态网站上添加用户生成的内容是一个有点挑战的问题。以博客的评论系统为例–你如何处理用户的评论并将其附加到只使用普通HTML页面的文章中？你不能这样做。
解决方案
你不能绕过这个限制本身，在你的静态页面中开始处理数据，但你可以为个别情况找到替代的解决方案。如果你需要创建一个联系表，有很多第三方服务可以处理POST请求，并将数据通过电子邮件发送给你，或将其导出为你选择的格式。
不过，评论系统是一个稍微不同的动物，因为它不仅涉及到处理用户数据，而且还涉及到将其附加到某个页面。像Discuz这样的平台经常被用来作为一种变通方法，它们也能做到这一点，但我个人并不是一个大粉丝。
首先，我们在第1点中讨论过–Disqus会在提供评论后用JavaScript将其附加到页面上，所以技术上来说，在JavaScript启动之前，评论并不存在于你的网站上。其次，这种方法与把内容放在一起并在一个资源库中进行版本管理的前提相矛盾。
我曾经写过一篇关于Jekyll评论系统的文章，它基本上使用一个服务器端处理程序来处理评论，将它们添加到仓库并推送到GitHub，使评论与网站的其他内容保持一致。
3) 没有管理界面
在WordPress或Medium上发布一篇博文是非常容易的。它可以从任何地方，甚至从手机上完成，而不需要安装任何额外的软件。而静态网站就不是这样了。
通常情况下，文章是在文本编辑器中组成的，并以Markdown或Textile这样的语言进行格式化。要发布它们，你需要重新生成网站（大多数引擎有一个观察功能，可以检测文件变化并自动重新生成网站）并将文件部署到服务器上。用一部坐在沙滩上的手机做这些事有点困难，不是吗？
解决方案
有一些平台提供网页界面，可以直接在GitHub仓库上创建、编辑和删除文件，为Markdown提供所见即所得的编辑器，创造一个友好的组成界面。例如prose，一个免费的开源解决方案，或者更高级的CloudCannon，一个商业产品，允许用户编辑静态网站的整个部分，并看到实时预览的变化。
还有一些移动应用程序，可用于iOS和Android，对于有兴趣在移动中编写和发布内容的人来说是一个可行的选择。这些应用与GitHub连接，修改内容会被即时推送到仓库中。
另一个选择是建立一个允许用户通过电子邮件发布到静态博客的服务，对于那些需要不断在移动中写作的人来说，这可能是一个可行的解决方案。它的工作原理是监听某个地址的电子邮件，并从主题行中获取帖子的元数据，从附件中获取图片，从信息本身获取帖子正文。
结论
转向静态网站有可能为你节省时间和金钱，因为它需要较少的维护和较少的服务器资源。它们是可靠的，可扩展的，可以很好地处理大量的流量。
2012年，奥巴马的总统竞选通过Jekyll网站筹集了2.5亿美元的资金。2013年，Healthcare.gov也使用Jekyll切换到了无CMS的方式。静态网站正在为巨大的项目提供动力，而且绝对不限于博客。也有一个强大的开源社区在维护和推动各种不同口味和功能的引擎。
然而，静态网站并不是一些能够解决所有问题的神奇的解决方案–它们在某些情况下是完美的，但在其他情况下却很糟糕。了解它们如何工作以及它们能做什么是至关重要的，以便在每个项目的基础上评估它们是否是工作的正确工具。