Markdown似乎比HTML更容易编写和编辑。我见过的所有HTML编辑器都输出了大量不必要的垃圾。降价似乎更干净。
以下是我正在考虑做的事情：将 markdown 存储在数据库中，使用 PHP Markdown 将其转换为 HTML，然后将其输出到 Web 浏览器。
一个问题是每次请求页面时都必须执行此操作。这似乎有些昂贵。
这是个好主意吗？或者有更有效的方法吗？
作为一个实际的例子，Stack Overflow支持Markdown（如你所知），但将Markdown和渲染的HTML都存储在数据库中。这使得提供页面的速度要快得多，因为呈现的 HTML 始终相同。帖子的创建频率远低于向用户显示的频率。
从你的网站上退后一步，问问自己它到底有多"贵"。 您是否每天提供超过 1,000 个独立服务？ 实际上，它会膨胀吗？ 对于所有这些问题，答案并不明确。 例如，当我为一家国际银行构建网站时，一个非最小化的 CSS 文档每天可能会增加 1 GB 的带宽。 但是，当我构建我的投资组合网站时，我期望获得一小部分流量。
我当然不主张构建低效的代码。请记住，"成本"实际上应该以流程时间执行来衡量，而不仅仅是流程。
如果您真的担心，请记录执行 PHP Markdown 进程之前和之后的时间。 然后，以 A/B 方式跟踪一段时间的服务器负载。 数字不会说谎。
我最近完成了一个与你所问的非常相似的项目。我没有将完整的HTML存储在数据库中，而是选择使用专有API将标记的html存储在文件系统上，就像MongoDB一样。存储降价与全面降价的美妙之处在于文件系统上的占地面积要小得多，如果您需要查看原始降价，它更容易阅读。当用户编辑 html 时，我会渲染完整的内容，以便他们可以看到它的外观。
还有其他关于存储两者的建议，我不太同意。如果您希望通过不必为每个请求标记降价版本来提高性能，那么我会考虑在每次编辑时缓存完整版本。同时存储降价和全面降价会破坏降价的目的，因为您需要在磁盘空间和/或数据库操作中付出代价。
您可以同时存储两者。如果必须多次编辑存储的 Markdown，或者如果开发了另一个或更好的 Markdown 到 HTML 翻译，则存储的 markdown 很有用。正如您所说，存储的 HTML 很有用，可以避免一次又一次地重新生成它。