让“发布”真正成为发布：Nami 的自动更新实践

发布一篇文章，本来应该是一件很简单的事。 写完，检查，点击“发布”，然后去前台阅读。用户不应该知道数据库发生了什么，也不应该为了看见新文章，再跑到 Cloudflare 控制台点击一次“重新部署”。 但对于静态博客来说，事情并没有表面上这么简单。 ### 数据已经更新，页面却还停在过去 Nami 的文章保存在 Cloudflare D1 中，前端则使用 Astro 生成静态页面。 这种架构的优点很明显：访问速度快、搜索引擎友好，而且绝大部分请求都由 Cloudflare Pages 的边缘节点直接响应。对于一个轻量博客来说，这套方案很合适。 问题也同样明显。 当后台把新文章保存到 D1 后，数据库里的内容虽然已经更新，但之前生成的 HTML 文件并不会自动改变。于是就会出现一个让人困惑的现象：后台明明显示发布成功，API 也能查到文章，前台却依旧看不到。 如果每次发布都要求用户手动重新部署，那么后台的“发布”其实只完成了一半。 ### 一次看似正常的空页面 这次排查还发现了一个更隐蔽的问题。 文章列表页在构建时请求了 500 篇文章，但公开 API 规定一次最多返回 100 篇。API 正确地返回了参数错误，前端却把这个错误当成了“没有文章”，最终生成了一个显示“暂无文章”的静态页面。 这比直接构建失败更麻烦。 因为 Cloudflare 会告诉你部署成功，页面也确实能够打开，只有内容悄悄消失了。表面上的成功，反而掩盖了真正的错误。 现在，列表请求已经改为 API 允许的数量。生产构建如果无法读取公开内容，也会直接失败，不再用空页面冒充一次成功部署。 ### 让发布形成完整闭环 新的发布流程是这样的： 1. 管理员在后台发布公开文章； 2. Workers API 将文章写入 D1； 3. Worker 安全地调用 Pages Deploy Hook； 4. Cloudflare Pages 获取最新公开内容； 5. Astro 重新生成首页、文章列表、详情页、分类页、标签页、RSS 和 Sitemap； 6. 后台提示“前台正在自动更新”。 Deploy Hook 只保存在 Worker Secret 中，不会进入 GitHub 仓库，也不会出现在浏览器代码里。 如果 Hook 暂时失败，文章仍然会安全地保存在 D1 中。后台会明确告诉管理员：内容已经保存，但自动更新失败。这样既不会丢失文章，也不会让失败悄无声息。 ### 不是所有操作都需要重新构建 自动化并不意味着每次点击都要触发一次部署。 草稿和非公开文章不会出现在前台，因此不需要构建。待审核友链和评论属于运行时数据，也不应该浪费 Pages 的构建次数。 主题选择同样改成了“先预览，后保存”。管理员可以在后台反复比较不同主题，只有点击“保存设置”时才会真正写入配置并触发一次前台更新。 好的自动化不是触发得越多越好，而是在正确的时间完成正确的工作。 ### 静态站点也可以拥有自然的发布体验 我们最终还是保留了 Astro SSG。 没有为了追求即时更新而把整个博客改成动态渲染，也没有增加新的服务器和复杂依赖。Nami 仍然是一套轻量、快速、适合 Cloudflare 免费服务的博客系统。 变化只发生在发布链路上。 现在，当我点击“发布”时，它不再只是把一条记录写进数据库，而是会把文章真正送到读者面前。 这才是一个发布按钮应该完成的事情。 而这篇文章，正好用来验证它。