为什么我把这个站点做成静态的

搭这个站点的时候，我给自己定了一条约束：更新一篇文章的成本，不应该高于写一篇文章。

这条约束淘汰掉了很多看起来更专业的方案。

淘汰掉的选项

CMS。多一个后台就要多维护一套账号、权限、数据库备份。对个人站点来说，维护成本远大于收益，而且一旦后台挂了，连文章都发不出去。

前端框架 + SSR。为了一个每几天更新一次的内容站引入一整套构建链，意味着每次升级依赖都要冒一次风险。内容与框架版本绑死，两年后想改一个样式可能要重写。

数据库驱动的动态站。最快的方案往往是最脆弱的方案。

最终方案

三层，每一层都可以被单独替换：

content/     ← 我写东西的地方，Markdown + JSON
scripts/     ← 一个不到 300 行的 Node 构建脚本
public/      ← CSS、JS、图片，没有构建步骤，直接拷贝

GitHub 收到 push 之后，Cloudflare Pages 自动执行构建命令，把生成好的静态文件发布到全球节点。

日常更新的动作只有一个：往 content/posts/ 里丢一个 Markdown 文件，然后 push。

为什么是静态

三个理由，按重要性排序：

1. 零运行时依赖。 没有数据库、没有服务端进程、没有需要打补丁的中间件。十年后这些 HTML 文件还能打开。
2. 成本结构清晰。 托管免费，流量成本可忽略，不需要为「可能用不到的扩展性」预付费用。
3. 迁移成本低。 整套东西就是一个文件夹加一个脚本，换任何一家托管商都能跑。

一个副作用

静态化的一个意外好处是写作门槛变低了。

因为没有后台、没有预览环境、没有发布按钮，写东西这件事回到了它本来的样子：打开编辑器，写 Markdown，保存。所有的仪式感都被去掉了，剩下的只有内容本身。

工具的复杂度应该和内容的重要性成反比。内容越重要，工具越该简单。

这也是为什么这个站点的设计这么克制——我不想让视觉抢走内容的注意力。