为什么我选择 Astro + GitHub Pages

写博客这件事，真正难的通常不是“把第一版做出来”，而是后面能不能低负担地持续更新。

我最后选择 Astro + GitHub Pages，核心原因只有一句话：它足够轻，而且长期维护成本低。

为什么是 Astro#

Astro 最打动我的地方，是它很适合“以内容为中心”的站点。

1. 页面结构很清楚#

我不需要一个很重的运行时，也不需要为了展示几篇文章就引入复杂的前后端分层。Astro 的页面、布局和内容目录都比较直接，读起来像在整理文档，而不是在维护一套庞大的应用。

2. 对 Markdown 和 MDX 友好#

我平时写作本来就偏向 Markdown，所以理想状态应该是：

1. 新建文章
2. 填好 frontmatter
3. 正常写内容
4. push 之后自动发布

Astro 的 Content Collections 正好把这一套约束得很舒服，既保留了 Markdown 的轻量，也有类型检查，不容易把文章元数据写乱。

3. 静态输出很适合博客#

博客天然适合静态化，访问快、部署简单、出问题的面也少。对于个人站点来说，这种“简单可靠”比花哨更重要。

为什么是 GitHub Pages#

GitHub Pages 的优势在于，它和仓库工作流贴得非常近。

需求	解决方式
托管静态文件	GitHub Pages
自动构建	GitHub Actions
内容版本管理	Git
自定义域名	CNAME + DNS

对个人博客来说，这套组合已经很完整了。你不需要额外购买部署平台，也不用维护服务器进程。

我想要的写作体验#

我希望后续维护这个站点时，尽量只关注两件事：

• 文章本身写得够不够清楚
• 页面是否还保持安静、克制、可读

比如创建新文章时，我更期待这样的命令：

pnpm new-post "我最近的写作方法"

然后我只需要进入 src/content/blog 把正文写完即可。

最后#

技术栈从来不是目的，它只是把写作这件事变得更顺手一点。如果一套方案能让我在半年后还愿意继续更新，那它对我来说就是好方案。