为什么我选择 Astro 搭建个人博客

个人博客是个「低频更新、长期在线」的东西。选框架时我问自己的第一个问题不是「哪个最流行」，而是：五年后我还会愿意为它写文章吗？

内容站点的本质需求

对博客来说，真正的用户价值只有一件事：把文字送到读者眼前。由此倒推出硬需求：

1. 写作体验简单 —— 一个 Markdown 文件就是一篇文章
2. 打开速度要快 —— 读者从搜索进来，3 秒打不开就走了
3. 维护成本要低 —— 不应该每个月都在升级依赖
4. 内容可迁移 —— 不被某个平台锁定

按这四条去筛，很多「全功能框架」反而是负担。

为什么不是 Next.js

Next.js 很强，但强在应用侧：SSR、动态路由、API、鉴权。博客用不到这些能力，却要背起整套运行时和构建复杂度。

更实际的问题是内容模型。博客的核心数据是 Markdown，而 Next.js 的官方内容方案（MDX / Contentlayer）需要自己组装：frontmatter 校验、路由生成、RSS、分页，每一件都要找库或手写。

为什么不是 Hugo

Hugo 的构建速度至今无人能打，模板语言也够用。放弃它的原因很私人：

• Go template 的心智负担高，改一个组件经常要查语法
• 自定义交互（比如首页的 Three.js 场景）需要自己接前端打包链路
• 语法细节（{{ range }}、partial 调试）对我太不友好

工具如果用起来不顺手，我就不会愿意为它写东西——这是博客的死穴。

Astro 的契合点

Astro 做对了三件事：

1. Content Collections src/content/blog/*.md 加一个 schema，frontmatter 写错构建直接报错。这一条就值回票价。

2. 岛屿架构 默认零 JS，需要交互的组件（搜索框、3D 场景）单独声明 hydration。装饰性的 Three.js 可以按需加载，不拖累阅读页。

3. 部署简单 astro build 输出纯静态文件，推到 GitHub Pages 就完了。没有服务器，没有冷启动，没有月账单。

代价与取舍

Astro 不是免费的午餐：

• 生态比 Next.js 小，冷门问题搜不到答案
• React 岛屿引入时，打包体积仍会回来（我首页的 Three.js 就是反例）
• i18n、评论等能力需要第三方拼装

但这些都在「可控」范围内——个人博客不需要平台级的解决方案。

一句话总结

框架应该为内容服务，而不是内容迁就框架。 对我而言，Astro 的抽象层级刚好贴合博客的本质：文件即文章，构建即发布。

如果你也在选型，建议先写下自己的四条硬需求，再去看工具。答案通常会自然浮现。