把博客做成一件可以长期使用的工具

示例文章：以下是用于展示阅读体验的可替换内容，不代表作者已经完成的项目或真实经历。

一个博客首先是写作的地方。文章能够快速打开，网址可以被分享，几年后的自己还能找到旧内容，这些朴素的目标，比不断更换技术栈更值得优先考虑。

先让内容有自己的位置

把文章保存为 Markdown，会让正文脱离某个特定编辑器。标题、摘要、分类与发布日期留在元数据中，图片与文字则一起进入版本记录。修改一篇文章时，能够明确看到自己改变了什么。

内容模型也可以很小。一份永久保留的文章标识负责连接未来的数据，一个可读的 slug 负责网址。标题可以重新斟酌，文件可以移动，文章的身份依然连续。

把复杂度放在需要它的地方

正文、列表与关于页适合预先生成。搜索、主题切换与移动导航只在需要交互的局部运行。阅读一段文字，不应该以加载整套应用状态为前提。

下面是一段概念示例，用来表达发布规则；实际项目应该让这一规则只有一个实现入口。

const isPublished = (article, now) => {
  return !article.draft && article.publishedAt <= now;
};

内容	主要目标	适合的处理方式
文章正文	快速打开、易于索引	静态 HTML
主题切换	响应个人偏好	少量客户端脚本
文章搜索	找到已有内容	按需加载本地索引

给未来的自己留下一张地图

项目结构应该帮助人找到问题。页面负责组装，内容模块负责规则，展示组件负责表达；当一个功能变化时，可以推测应该查看哪些文件。

• 为每个目录写清职责，不用目录数量证明架构完整。
• 把文章字段规则集中维护，减少重复解释。
• 记录真正影响以后选择的决定，以及当时的理由。
• 保留一个能够快速执行的检查入口。

长期维护往往来自这些细小约定。等到文章逐渐多起来，它们会让写作和改进网站都更轻松。