这个博客的第一篇文章，写的是它怎样工作。

给 GitHub Issue 加上 blog 标签，Astro 在构建阶段读取正文，再把静态页面发布出去。链路跑通以后，我很快发现，「能不能拿 Issues 做博客」其实是最不重要的问题。

当然能。

更值得问的是，真的这样写上一段时间以后，我得到了什么，又把哪些能力留在了门外。

它最先省下来的，不是服务器钱，而是一次心理切换

独立博客后台通常会带来账号、数据库、编辑器、图片上传、备份和部署。这些能力都很正经，也都可能在某一天变成需要处理的维护事项。

GitHub Issues 已经有我写技术文章常用的部分。Markdown、历史记录、标签、评论、稳定编号和自动化事件都在，而且我每天本来就会打开 GitHub。

这点对我比功能列表更重要。

想写一篇文章时，我不用先切换到一个专门的内容工作台，也不必回忆某套后台上次升级是什么时候。文章和开源项目继续待在同一个身份里。偶尔写作的人，往往不是被缺少高级功能拦住，而是被一次又一次很轻的启动成本劝退。

Issues 把这个成本压得足够低。

内容模型越朴素，我越不担心以后搬家

当前模型几乎没有需要解释的地方。Issue 标题就是文章标题，正文是 Markdown，编号是稳定 ID，blog 标签决定是否发布，其他标签可以做分类，评论留在原 Issue。

我故意没有先设计一大套 frontmatter。发布日期可以来自 Issue，正文保持普通 Markdown。将来如果不再使用 GitHub，通过 API 导出成文件也不需要先理解一套只属于这个博客的数据库结构。

平台绑定当然仍然存在。编辑历史、评论身份和自动化事件都属于 GitHub。但文章最重要的部分没有被锁进私有格式，这让我更愿意接受当前的便利。

低维护不等于永远不迁移，而是迁移那天不会先面对一堆无法带走的内容。

内容在 GitHub，阅读现场不必依赖 GitHub

最省开发时间的办法，是访客打开页面时让浏览器直接请求 GitHub API。这样做也会把 API 限流、网络延迟和 GitHub 可用性一起带到阅读现场，首屏内容还要等客户端 JavaScript 拉取。

所以博客在 Astro 构建阶段分页读取所有带 blog 标签的 Issue，排除 Pull Request，再生成静态文章页、RSS、Sitemap 和元数据。访客拿到的是已经完成的 HTML、CSS 与少量交互脚本。

这条边界让我很安心。API token 只存在于构建环境，页面访问不消耗 GitHub API，请求失败也只影响一次构建，不会让每位读者分别遇到。以后换到别的静态托管，内容生成方式仍然成立。

内容源放在 GitHub，不代表运行时也要被 GitHub 牵着走。

发布很轻，预览和内容运营就没那么舒服了

写完 Issue，加标签，等待构建。这套发布动作很贴近我的日常工作流。草稿也可以先不加 blog，准备好以后再公开。

但 Issues 编辑器毕竟不是长文 CMS。它看不到博客真实样式，图片管理、系列文章、定时发布和多语言关联都需要额外约定。文章多起来以后，标签与搜索也未必比专业后台好用。

自动化还有自己的脾气。创建、编辑、加标签和评论都可能触发工作流。监听太宽，一次小改动产生一轮没必要的部署；监听太窄，正文修正以后公开站点又停在旧版本。并发取消、触发条件和最终构建内容，都得认真定义。

这些不是方案失败，而是它换来的真实边界。Issues 让我少维护一套内容系统，却没有凭空获得专业内容运营能力。

GitHub 评论很好用，也确实把一些读者挡在门外

把讨论入口指回原 Issue，不需要另外保存访客数据，也不用维护反垃圾系统。技术读者还能直接引用代码、提交和其他 Issue。

代价同样明显。没有 GitHub 账号，或者不愿意登录 GitHub 的读者，只能看，不能说。评论也会离开站内阅读现场，跳回一个更像工程协作的界面。

对开发者导向的个人博客，我愿意接受这件事。如果面向更广的人群，它就不再是一个可以顺手略过的取舍。

我会把它推荐给和我处境相似的人

更新不算频繁，内容以技术实践为主，作者本来就在 GitHub 工作，也不需要多人审核和复杂排期。这样的博客很适合拿 Issues 做内容源。

如果要做商业内容运营、富媒体专题或多人编辑，它大概率会很快碰到天花板。那时专业 CMS 增加的维护成本，可能正好是在购买需要的能力。

我现在仍然喜欢这套方案，不是因为它证明了 Issue 什么都能做。恰恰相反，我喜欢它知道自己只需要做多少。

第一篇文章问这个博客怎样工作。真正用起来以后，我的答案变得更简单了。

它好用，是因为它没有让我先维护博客，才能继续写博客。