为什么大多数 CMS 不将静态 .html 文件写入磁盘？
对于不需要评论等动态功能的基本 CMS，为什么不将静态 .html 文件写入磁盘呢？然后可以使用像 nginx 这样的高性能静态文件 Web 服务器来提供文件服务。理论上，这将提供尽可能最高性能的网站。
编辑：在我看来，“基本 CMS”是公司可以用于其公司网站的东西。内容需要改变我的营销人员，但通常没有像评论这样的动态内容。
For a basic CMS that does not require dynamic functionality like comments, why not write static .html files to disk? Then a high-performance, static file, web server like nginx could be used to serve the files. This would theoretically deliver the highest performance web site possible.
EDIT: "Basic CMS", in my mind, is something a company could use for their corporate site. The content needs to change my a marketing person, but there typically is no dynamic content like comments.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
原因之一是，即使是基本网站也会大量使用“动态”内容。
考虑一下最新文章的侧边栏 - 如果网站是静态 HTML 页面，则每次发布新帖子时可能都需要重写网站的每个页面。
但是，如果高流量意味着响应每个请求而提供动态内容会成为性能问题，那么许多 CMS 可以缓存其内容，从而有效地实现两全其美。
One reason is that even basic sites make extensive use of 'dynamic' content.
Consider a sidebar of the most recent articles - if the site was static HTML pages, every single page of the site might have to be rewritten every time a new post was published.
But if high traffic means that serving dynamic content in response to every request becomes a performance issue, many CMSs can cache their content, effectively giving the best of both worlds.
虽然这不是对您问题的直接答案，但我记得最近读到的一些关于此问题的博客文章，您可能会感兴趣：烘焙与烹饪。
它描述了将 WordPress 博客转换为“烘焙”解决方案的过程。
Though this is not a direct answer to your question, I remembered some blog post I recently read about this, which might be of interest to you: baking vs. cooking.
It describes the conversion of a WordPress blog into a "baked" solution.
如果任何内容都没有发生变化，那就没问题了。一旦发生变化，您需要重新生成 html。即使您没有评论，也可能是在使用 CMS，因为您的内容有可能发生更改。
CMS 会有一个缓存，但它仍然需要检查自上次生成 html 以来是否有任何内容发生更改。缓存也会占用磁盘空间——虽然不是一个大问题，但也是一个考虑因素。
因此，根据内容更改的频率以及内容的多少，预先生成 html 可能没有意义。
That would be OK if none of the content ever changed. As soon as something changes you need to regenerate the html. Even if you don't have comments, presumably you are using a CMS because your content has the potential to change.
A CMS would have a cache, but it still needs to check to see if any of the content had changed since the last time the html was generated. The cache also takes up disk space - while not a big issue, it is a consideration.
So depending on the frequency with which the content changes and how much content there is, it might not make sense to pregenerate the html.
当您说静态内容时，大多数 CMS 都假定其内容需要固定，但需要可编辑。我相信这就是为什么它们从未写入 html 并保存到数据库的原因。
When you say static content, most CMSs assume its content that needs to be fixed, but needs to be editable. I believe that's the reason why they're never written to html and saved to a database instead.
大多数 CMS 可能需要一些动态功能。
但有一些，特别是博客引擎，可以按照您所描述的方式工作。它是生成博客的一组脚本，包括原子提要。
看看 utterson 的例子：
http://github.com/stef/utterson
Most CMS probably need some dynamic features.
But there's a few, specially blog engines, that work the way you described. It's a set of scrips that generate a blog, including atom feeds.
Take a look at utterson for example:
http://github.com/stef/utterson
原因之一是 SQL 解决方案允许您将布局和模板问题与数据本身分开。因此，您的内容与结构的变化无关，这使得事情更容易管理。使用基于文件的方法，对结构的任何更改都需要您删除并重写所有现有内容。
One reason would be that a say, SQL, solution allows for you to separate your layout and template concerns from the data itself. Your content is therefore agnostic to changes in structure, which makes things easier to manage. With a file-based approach, any change to your structure would require you to delete and re-write all existing content.
因为大多数 CMS 需要某种描述的动态功能（或者至少将其作为一项功能，因此围绕该需求设计其架构）。
此外，大多数 CMS 都不是“基础”的 - 它们是高度复杂的“万事通”网络应用程序，其功能通常远远超过您想要/需要的功能 - 大部分都是动态的。
正如您所描述的那样，许多 CMS 都会进行缓存，并且大多数 CMS 没有某种模块/插件/等。确实如此。例如，Drupal 有 Boost： http://drupal.org/project/boost
Because most CMSes require dynamic functionality of some description (or at least have it as a feature, and therefore design their architecture around that need).
Also, most CMSes are not "basic" - they're highly complex "jack-of-all-trades" webapps that often do far more than you want/need - most of it dynamic.
Many CMSes do cache as you've described though, and most of the ones that don't have some kind of module/plugin/etc. that does so. Drupal for example has Boost: http://drupal.org/project/boost