搭博客之前，我是怎么选技术栈的

我是前端开发，所以刚准备做博客时，脑子里最先冒出来的其实不是 Astro，而是 Vue 和 React。

这很正常。平时写业务，大多数时候本来就是围着组件、状态、路由和工程化在转。要做一个网站，第一反应当然是：那我直接用熟悉的前端技术栈不就行了？

我一开始也是这么想的。

但真准备开工时，我发现顺序还是有点反了。

博客当然可以直接用 Vue 或 React 做，而且不是不能做，是真的能做。

问题不在“能不能”，而在“值不值”。

博客不是后台系统，也不是交互特别重的 Web 应用。它最核心的问题其实很朴素：内容怎么写、页面要不要快、后面会不会难维护、以后想加功能时会不会推倒重来。

所以这篇不讲“怎么从零搭一个博客”，而是讲更前面那一步：博客网站在开工前，到底该怎么选技术栈。

先别选框架，先回答这 4 个问题

如果这几个问题没想清楚，后面很容易变成“明明只是做个博客，结果把项目做成了半个内容平台”。

1. 内容是不是主角 如果网站 80% 都是文章、归档、标签、目录、封面图，那它本质上就是内容站。内容站最怕的不是功能少，而是链路太重。

2. 前期到底要多少交互 如果只是目录高亮、代码复制、搜索、评论，这类交互其实都不重，没必要一上来就为整站引入复杂的客户端渲染。

3. 文章怎么生产 你是自己写 Markdown，还是准备接 CMS？如果前期主要靠本地写作和 Git 管理，那静态内容方案会轻松很多。

4. 半年后可能加什么 如果你很确定后面会上会员系统、订阅、后台编辑器、个性化推荐，那选型就要往应用型框架靠。反过来，如果半年内都只是稳定发文，那就别把栈堆太满。

博客技术栈，其实可以拆成 6 个决定

我后来发现，“选技术栈”这件事说大也大，说小也小。真拆开看，无非就是下面这几个部分：

层	我要决定什么
框架	页面怎么生成，开发体验怎么样
内容方案	文章放哪，怎么组织，能不能做校验
样式方案	写样式顺不顺手，后面维护累不累
搜索	站内搜索要不要自己托管
评论	是不是接第三方，维护成本高不高
部署	发布是否简单，静态资源是否稳定

这样拆开之后，事情会清楚很多。你不是在几个大框架里“站队”，而是在给博客补一套刚好够用的组合。

我为什么最后没有停在 Vue 或 React 本身

我后来犹豫的点主要有两个。

第一，Vue 和 React 更像基础能力，不是博客方案本身。

你当然可以拿它们搭，但搭博客时你还得继续补：

• 内容从哪来
• Markdown 怎么组织
• 路由怎么约定
• 文章字段怎么校验
• 静态构建链路怎么收拢

也就是说，直接选 Vue 或 React，很多时候只是把问题往后推了一步。你还是得再决定：是走 VitePress、Next.js、Nuxt Content、Astro，还是自己拼。

第二，博客的重点和业务系统不太一样。

业务项目里，我更在意组件复用、状态管理、交互一致性。博客这种内容站里，我更在意的是：

• 文章维护顺不顺
• 页面是不是够轻
• 构建和部署麻不麻烦
• 后面加目录、搜索、归档时会不会越来越臃肿

当我开始按这个标准看时，视角就从“选前端框架”慢慢变成了“选内容站方案”。

为什么我最后会偏向 Astro

把需求摊开以后，Astro 几乎就是顺着问题走出来的结果。

原因不复杂，主要就这几条：

• 博客是内容站，静态生成天然合适。 大部分页面在构建时就能产出，访问时不用再临时算一遍。
• 默认发给浏览器的东西更少。 这一点对博客很实在，首屏更轻，页面负担也更小。
• 要交互时也不是完全没路。 像目录、搜索框、评论区、局部小组件，都可以按需加，不用让整站一起变重。
• 内容组织比较顺手。 Content Collections 这套东西对博客挺友好，文章字段能约束，维护时不容易写乱。

更关键的一点是：它让我不用先站在 Vue 或 React 其中一边，再去给博客补齐一堆内容站能力，而是直接从“我要做一个内容站”出发。

我当时并不需要登录、支付、复杂接口，也不需要一套很重的服务端能力。既然如此，就没必要先把应用型框架的成本背上。

那为什么不是 Vue 生态或 React 生态里的别的方案

不是说它们不好，而是看你到底要借它们解决什么问题。

如果你本来就长期写 Vue，那你很可能会先看 Nuxt 或 VitePress。如果你长期写 React，那你大概率会先看 Next.js。这条路径很自然，我自己也完全能理解。

而这些方案什么时候更合适？通常是你准备把博客继续做成一个更完整的产品，比如：

• 有账号体系
• 有后台管理
• 有大量个性化内容
• 有比较重的服务端逻辑

那 Next.js 或 Nuxt 都很合理，因为它们处理这类需求会更顺手。

但如果眼前的目标就是先把博客稳定上线，文章好写、页面够快、部署别折腾，那我更愿意先选轻一点的方案。先把网站发出去，比提前拥有一堆“以后也许会用到”的能力更重要。

除了框架，配套工具我怎么定

框架定完以后，剩下的选择反而不用太纠结。我给自己的原则一直是：能少一层，就少一层。

最后我会优先考虑这样的组合：

需求	方案	我看中的点
内容管理	Markdown + Content Collections	写作直接，版本可追踪，字段能校验
样式	Tailwind CSS	改页面快，做博客足够灵活
搜索	Pagefind	静态站友好，不急着上外部服务
评论	Giscus	省掉自建评论系统的维护
部署	Vercel 或 Cloudflare Pages	发布简单，静态站支持成熟

这里面我最在意的不是“功能最多”，而是“先跑起来之后，后面别总想重构它”。

比如评论区这件事，自建当然自由，但我很清楚自己前期不会把时间花在反垃圾、审核、通知和用户体系上。那第三方方案就更合适。

搜索也是一样。博客前期文章不多时，先用静态搜索完全够用。等内容量真上来了，再考虑更重一点的方案也不迟。

有些东西，我会故意先不做

前期选型最容易踩的坑，不是选错，而是一次加太多。

这些东西我通常会延后：

• 自建 CMS
• 自建评论系统
• 为了“以后可能要用”提前上数据库
• 没多少内容时就接很重的搜索服务
• 还没稳定发文，就先折腾一套复杂的组件体系

这些方案不是不能做，只是它们更适合在网站已经跑起来、内容节奏稳定之后再上。前期最值钱的，往往不是架构想得多远，而是你能不能持续把文章发出来。

如果你也要搭博客，可以按这个顺序做决定

我自己现在会按下面这个顺序走：

1. 先确认博客是不是典型的内容站
2. 再确认半年内有没有重服务端需求
3. 没有的话，优先考虑静态生成方案
4. 再补内容管理、样式、搜索、评论和部署
5. 最后才考虑那些“以后也许会用”的扩展能力

这个顺序有个好处：你会更容易做出一个刚好够用的站，而不是做出一个配置很全、但一直没真正写起来的项目。

小结

回头看，博客网站前期选型最重要的不是“Vue 还是 React”，也不是“哪个框架最强”，而是你到底要做一个什么样的网站。

如果它本质上是内容站，那我会优先看这几件事：文章生产顺不顺、页面够不够轻、后期维护麻不麻烦、部署是不是省心。沿着这条线走，Astro 这样的方案就很容易进入候选。

但这不代表 Vue 或 React 不适合做博客。更准确地说，它们当然可以做，只是对我当时那个阶段来说，我更想先选一套更贴近内容站的问题模型，而不是从熟悉的前端技术出发，再一点点把博客能力补出来。

先把内容发布这件事跑顺，再去补更复杂的能力。对博客来说，这个顺序通常更靠谱。