为什么我选择 Astro 重建博客

上一版博客跑在一个全家桶框架上：路由、状态管理、按需加载一应俱全。回头统计，后台改一篇文章要经过六个环节，而九成页面其实一年不改一个字。于是我决定重建，方向很明确——内容优先、构建时静态化、运行时零 JavaScript。

选型的三个标准

这次选框架只有三条标准：

1. Markdown 是一等公民：写作流程必须是「编辑 .md → 提交」，中间没有任何转换步骤；
2. 构建产物是纯静态文件：可以部署到任何静态托管，不需要 Node 运行时；
3. 默认零 JS：交互只出现在真正需要的地方，而不是每个页面都背上一个框架运行时。

Astro 恰好按这个顺序思考问题。它的内容集合把 Markdown 文件变成一个带 schema 校验的数据源，astro build 之后 dist/ 里就是可以扔到任何 CDN 的 HTML。

内容模型比框架更重要

框架会换代，内容模型会留下来。我的内容集合只有一篇文章实体，frontmatter 严格限定在七个字段：

title: 标题
description: 摘要
pubDate: 2026-07-18
updatedDate: 2026-07-20 # 仅在有实质修订时出现
category: 前端        # 单分类，必填
tags: [astro]         # 多标签，可空
draft: false          # 草稿不进构建产物

单分类 + 多标签的组合，来自对旧站数据的复盘：三年前我有七个分类，其中四个只有一篇文章。分类应该是「一级学科」，标签才是细粒度主题。约束即秩序。

把复杂度留在构建期

全文搜索是这次重建最典型的取舍。候选方案里，客户端搜索库需要我把全部文章正文塞进 JS bundle；而 Pagefind 在构建后对 dist/ 做索引，浏览器只下载它需要的索引分片。全文搜索这个功能因此不产生任何随文章增长的运行时成本。

暗色模式、RSS、sitemap 同理：能用构建期脚本解决的，就不写成运行时逻辑。

剩下的交给排版

重建最大的意外收获是：当技术栈只剩静态 HTML 和 CSS，设计反而有了空间。下一篇会写这个站点的「纸墨编辑部」视觉体系是怎么用 CSS 设计令牌搭出来的。