你好，世界：这个博客如何工作

这篇文章现在就躺在一个 GitHub Issue 里。

它不是从 CMS 同步过来的，也没有先写进某个数据库。标题是 Issue 标题，正文是 Markdown，blog 标签把它变成一篇文章。保存以后，剩下的事交给构建流程。

我一直想要一个自己的博客，但不太想为了写博客，再养一套只有写博客时才会打开的后台。账号、数据库、编辑器、备份、部署，这些东西当然都能做，只是每多一层维护，写下一篇的阻力就多一点。

所以这个博客的起点不是「我要做一个功能完整的内容系统」，而是一个更朴素的问题。

我能不能就在平时工作的地方写？

Issue 不是后台的替代品，而是我愿意打开的编辑器

对我来说，GitHub Issues 已经有不少写技术文章需要的东西。Markdown、修改历史、标签、稳定编号和评论都现成存在，文章和代码也继续留在同一个公开身份下面。

这套做法当然谈不上通用。要做多人审核、复杂排期、富媒体管理，专业 CMS 更合适。但个人技术博客最怕的往往不是能力不够，而是系统太郑重，郑重到每次想写点东西都觉得还得先进入「发布状态」。

Issue 刚好没那么郑重。我可以像记录一个工程问题那样写下想法，慢慢修改，准备好了再加上 blog 标签。这个动作和我原来的工作习惯很接近。

访客打开文章时，不会临时请求 GitHub API。Astro 会在构建阶段读取带有 blog 标签的 Issue，把标题和正文生成静态页面，同时产出首页、归档、RSS 和 Sitemap。

GitHub Issue
  → GitHub Actions
  → Astro 构建
  → 静态 HTML
  → GitHub Pages

这条链路里，我很在意构建阶段和访问阶段的区别。内容可以托管在 GitHub，但阅读不应该依赖浏览器现场请求 API。最终发布的是普通 HTML、CSS 和少量 JavaScript，GitHub API 限流或网络波动不会被转嫁给每一位读者，以后想迁移托管平台也不用重写内容。

换个角度看，Issues 只负责成为一个我用得顺手的内容源。网站怎样排版、怎样适配手机、怎样组织文章，仍然由博客自己决定。

后面我还会继续补阅读体验、分类、订阅和讨论入口，也会记录那些小项目背后的设计选择、开发过程和踩坑复盘。

不过我不想一开始就把博客做成另一个需要长期伺候的产品。功能可以慢慢长，写作入口最好一直简单。

如果这套系统真的有价值，不是因为「GitHub Issues 也能做博客」听起来有点特别，而是某天我想写东西时，不需要先想起后台密码，不需要更新编辑器，也不用检查数据库还活着没有。

我只要新建一个 Issue。

就像现在这样。