庭院的第一铲土：为什么我选择 Astro

建一个自己的网站，这件事我想了很久。

不是因为没有地方写字——笔记软件、文档、社交平台都可以。但我想要一个真正属于自己的角落：没有推荐算法，没有突然改变的产品规则，打开速度很快，夜里看起来也很好看。于是，庭院的第一铲土落在了 2026 年的夏天。

我到底想要什么

在选框架之前，我先写下三条不能妥协的需求：

• 内容优先。 写文章时只关心 Markdown，不必和组件树、数据请求搏斗。
• 默认很快。 首屏应该是 HTML 和 CSS，JavaScript 只在真正需要交互时出现。
• 可以长得很大。 标签、系列、搜索、评论以后都要加，结构不能一开始就绑死。

这三条听起来朴素，却直接排除了不少方案。

为什么不是 Next.js

Next.js 很强，生态也足够繁荣。但对一个以内容为主的博客来说，它带来的很多能力我都用不上：服务端渲染、增量静态再生成、Server Actions、路由缓存……这些概念本身没有错，只是当我只想写一篇文章时，它们像一整套需要维护的城市基础设施。

更重要的是，我不希望每次改一行 CSS 都要重新理解一次数据获取策略。博客应该像一座花园，而不是一座需要值班的机房。

为什么不是 Hugo

Hugo 的构建速度近乎魔法，单文件部署也非常优雅。真正让我犹豫的是模板语言。当我想在页面里做一点带类型的逻辑，比如「按系列排序并取出当前文章的上下篇」时，Go template 的表达力会迅速变成一场心智体操。

另外，Hugo 的生态更偏传统静态站点。我想在文章里放 MDX、在构建期做内容校验，这些在 Astro 里更自然。

Astro 的岛屿架构

Astro 最吸引我的一句话是：默认输出零 JavaScript。

页面在构建期被渲染成纯 HTML；只有被明确标记为客户端组件的「岛」才会带上 JS。对博客来说，这意味着滚动、排版、搜索弹窗这些交互可以单独加载，而正文永远是一张轻薄的纸。

---
// 默认：这段代码只在构建时运行
const posts = await getCollection('posts');
---

<Layout>
  {posts.map((post) => <PostCard post={post} />)}
</Layout>

这里的 PostCard 不会向浏览器发送任何组件运行时。它被渲染成 HTML，然后留在那里，像压在书页里的一朵干花。

Content Collections 带来的安全感

真正让我决定留下来的，是 Content Collections。

frontmatter 不再是无政府状态：字段缺失、分类拼错、日期格式不对，构建时就会报错，而不是等到线上页面变成一片空白。

import { defineCollection } from 'astro:content';
import { glob } from 'astro/loaders';
import { z } from 'astro/zod';

const posts = defineCollection({
  loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/posts' }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    category: z.enum(['tech', 'blender', 'cs']),
    tags: z.array(z.string()).default([]),
    series: z.enum(['blender-atelier', 'cs-notes', 'garden-devlog']).optional(),
    seriesOrder: z.number().int().positive().optional(),
    featured: z.boolean().default(false),
    draft: z.boolean().default(false),
  }),
});

这段 schema 像花园的篱笆。它不限制你种什么，但会阻止牛跑进来。

一张不太公平的对比表

维度	Astro	Next.js	Hugo
默认 JS 体积	接近零	取决于页面	接近零
内容建模	Content Collections	自由但需自建	frontmatter
模板表达力	TSX / Astro	React	Go template
构建速度	快	中等	极快
适合的场景	内容站、文档、博客	应用、混合渲染	大型纯静态站

「适合」比「先进」重要。框架不是勋章，它只是工具。

我放弃了什么

Astro 不是没有代价。

它的社区比 React 小，遇到冷门问题时搜索结果的密度更低；交互复杂的页面需要想清楚组件边界，否则会把岛屿切得支离破碎；而 View Transitions 与传统多页应用的心智模型不同，需要重新学习一套生命周期。

但这些代价换来的是：我打开任何一个页面，都能在源码里读懂它是怎么来的。

种子已经埋下

这一篇是「庭院建造日志」的第一篇。接下来我会记录这座网站如何一点点长出来：页面转场、中文搜索、代码高亮、Docker 部署，以及那些为了一个像素折腾到凌晨的时刻。

花园不是一天建成的。好消息是，它也不需要。

先种下一朵花，再考虑整片森林。