搭博客之前,我先问了自己一个问题:这个站点到底需要什么?
答案很朴素——写文章、放图片、偶尔加一点交互。没有用户登录,没有实时数据,也不需要复杂的后台。既然如此,把一个以内容为主的网站做成单页应用,反而是在给未来埋负担。
我想要的三个东西
选择框架时的三个硬指标
首屏要快
读者点开链接后,应该尽快看到文字,而不是先等一大包 JavaScript 下载和执行。
写作要简单
内容应该能直接写成 Markdown,而不是先学一套页面搭建系统。
交互要克制
只有真正需要交互的地方才加载脚本,其余部分保持纯静态。
Astro 刚好同时满足这三点。它默认输出 SSG 页面,组件在构建时渲染成 HTML;需要交互的部分再单独标记,作为「岛屿」加载。
静态生成不是退步
很多人把静态站点理解成「功能少」,但对我来说,它更像是一种取舍:把复杂度放在构建阶段,把简单留给访问者。
| 方案 | 首屏 | 运维 | 适合内容站吗 |
|---|---|---|---|
| 纯 SPA | 需要先加载框架 | 简单 | 一般 |
| 服务端渲染 | 依赖服务器 | 需要持续运维 | 可以,但偏重 |
| 静态生成 | 直接返回 HTML | 可以放在任意静态托管 | 很合适 |
对内容站来说,静态生成不是妥协,而是把复杂度放到了正确的位置。
真正吸引我的是内容集合
Astro 的 Content Collections 让 Markdown 不只是文件,而是有 schema 的数据。文章缺少标题、日期写错格式,构建阶段就会直接报错,而不是等发布之后才发现页面空白。
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。本站技术手记
连载中分享文章
生成精美分享图或复制链接,与更多人分享本文。
继续阅读
换条路线
从其他文章中稳定抽取
最后更新于 ,距今已过 13 天
部分内容可能已过时