770 字
4 分钟
为什么这个博客选择 Astro

搭博客之前,我先问了自己一个问题:这个站点到底需要什么?

答案很朴素——写文章、放图片、偶尔加一点交互。没有用户登录,没有实时数据,也不需要复杂的后台。既然如此,把一个以内容为主的网站做成单页应用,反而是在给未来埋负担。

我想要的三个东西#

选择框架时的三个硬指标

  1. 首屏要快

    读者点开链接后,应该尽快看到文字,而不是先等一大包 JavaScript 下载和执行。

  2. 写作要简单

    内容应该能直接写成 Markdown,而不是先学一套页面搭建系统。

  3. 交互要克制

    只有真正需要交互的地方才加载脚本,其余部分保持纯静态。

Astro 刚好同时满足这三点。它默认输出 SSG 页面,组件在构建时渲染成 HTML;需要交互的部分再单独标记,作为「岛屿」加载。

静态生成不是退步#

很多人把静态站点理解成「功能少」,但对我来说,它更像是一种取舍:把复杂度放在构建阶段,把简单留给访问者。

方案首屏运维适合内容站吗
纯 SPA需要先加载框架简单一般
服务端渲染依赖服务器需要持续运维可以,但偏重
静态生成直接返回 HTML可以放在任意静态托管很合适

对内容站来说,静态生成不是妥协,而是把复杂度放到了正确的位置。

真正吸引我的是内容集合#

Astro 的 Content Collections 让 Markdown 不只是文件,而是有 schema 的数据。文章缺少标题、日期写错格式,构建阶段就会直接报错,而不是等发布之后才发现页面空白。

src/content.config.ts
const posts = defineCollection({
loader: glob({ pattern: "**/*.{md,mdx}", base: "./src/content/posts" }),
schema: z.object({
title: z.string(),
published: z.date(),
tags: z.array(z.string()).optional().default([]),
}),
});

这段 schema 看起来普通,但它把「写作约定」变成了机器可以检查的规则。

部署也变得简单#

pnpm build 之后得到的是一个 dist/ 目录,里面全是 HTML、CSS、图片和少量按需加载的脚本。把它放到任意静态托管上就能访问,不需要 Node 进程常驻。

现在回头看,选择 Astro 并不是因为它「最新」或者「最流行」,而是因为它和我对博客的理解一致:内容应该比框架更重要。

Static Site Generation,静态站点生成,在构建阶段把页面预先生成成 HTML。

第 1 篇,共 12 篇本文属于系列

为什么这个博客选择 Astro
https://www.ycera.cn/posts/why-astro/
作者
初月_Yuechu
发布于
2026-10-20
许可协议
CC BY-NC-SA 4.0

分享文章

生成精美分享图或复制链接,与更多人分享本文。

继续阅读

沿着主题读

基于共同的标签与分类

换条路线

从其他文章中稳定抽取