这个博客为什么有两个后台

两套后台，各自解决什么

两者的差别不是「方便程度」，而是文章到底是什么。

线上后台里，文章是一条记录。它躺在云端的键值存储里，页面请求进来的时候被合并进去。所以「保存」这个动作改变的不是任何文件，而是下一次请求会读到什么。这也是为什么它不需要重新发布——因为压根就没有一份「发布产物」需要重新生成。

这里有个前提容易被忽略：站点已经不是纯粹的静态站了。它跑在 Cloudflare Pages 的进阶模式下，一个 Worker 接管全部请求，静态 HTML 只是基线，真实的页面是「基线 + 运行期改动」拼出来的。没有这层，线上改完立刻生效是不可能做到的。

本机编辑台里，文章是一个文件。它躺在磁盘上，能被版本控制、能被全文搜索、能被别的工具直接处理。代价是文件不会自己变成网页，改完得重新构建一次。

两种存法各有各的道理，谁也不能替掉谁。真正要避免的是第三种情况：同一个站上，一部分文章以一种方式存在，另一部分以另一种方式存在，而使用者根本不知道这件事。

一篇文章的一生

在这个站上，一篇文章会经过这么几种状态：

「已撤下」和「已删除」在结果上是一样的——都是看不到。区别在意图：撤下是「先收起来」，删除是「不想再要了」。但因为删除是可逆的，所以按错按钮不会造成不可挽回的后果。

「撤下」和「删掉」不是一回事

这是这个站最容易被误解的地方，值得单独说。

有一部分文章是构建期编译进静态产物的：它们不来自任何数据库，就长在 HTML 里。对这类文章，「删除」的正确做法不是删文件——那意味着要重新构建、重新上传，等于把一次轻量的编辑变成一次部署。

实际做法是写一条遮盖记录：请求进来的时候，凡是引用了这篇文章的地方，统统按遮盖记录过滤掉。文章文件原地不动，只是没人再看得见它。

这里有个必须说清楚的坑：一篇文章在页面上出现的地方，远比想象的多。稍微没改干净，就会出现「文章没了，但别的页面还挂着它的链接，点进去 404」。这个站最后整理出来的引用点是这些：

剩下的就是「机器读得到但人看不到」的部分了：结构化数据、接口返回的清单、被内联进搜索页的那份 JSON。漏掉任何一处，读者都会在某条意想不到的路径上撞见一篇已经撤下的文章。

也正因为这套机制是「遮盖」而不是「抹掉」，恢复才变得廉价：把遮盖记录撤掉，文章立刻回到所有位置。所以被删掉的文章在列表里会标着「已删除」，点一下就能找回来。

一个不可逆的删除按钮，配上一个把构建期文章和普通文章混在一起的列表，迟早会出事。可逆是刻意的。

关于站上最早的那三篇

这个站最早有三篇文章，是搭建时留下的样例：一篇讲搭建过程，一篇是 Markdown 语法速查，一篇是性能优化笔记。它们的作用是填充版式，顺便验证各种元素（表格、代码块、公式、引用、长列表）渲染出来是什么样子。

它们和后来写的文章没有任何区别——同样是构建期文章，同样可以撤下、删除、恢复。列表里它们会标着「站点原有」，方便区分。

没有做的事

一个能用的东西，边界和功能一样重要。这个站明确没做这几件事：

• 没有评论系统。页面上留了位置，但默认不启用。评论需要一个常驻后端，而「不依赖常驻后端」正是这个站建立的前提。
• 没有访问统计。想看清楚谁来过，就得引入第三方脚本，那是首屏渲染路径上一个纯粹的开销。
• 没有全文搜索服务。搜索索引在构建期生成、跟着页面一起发出去，匹配在浏览器里做。代价是索引有大小上限，好处是搜索不依赖任何服务端。
• 没有把「改内容」收敛到一处。两套后台并存是有意为之，理由上面已经写过。

这几条都是取舍，不是缺陷。写下来只是为了避免下次有人（包括以后的自己）以为它们是漏掉的。

所以，回到最开始那个问题：静态博客要不要后台？

要。只是它不需要一台服务器——它需要的是一条从「我想改」到「读者看到」之间尽可能短的路。这个站的做法是准备两条路，然后让两条路都保持可逆。