为什么这个站点选择 Astro 7

需求

这个站点的核心不是“应用”，而是“内容”：个人介绍、12 个项目案例、若干技术笔记。交互只有筛选、排序、搜索、主题与灯箱，没有登录、没有数据库、没有运行时后端。

需求可以归纳为四条：内容要能被类型系统约束、首屏要快、部署要零运维、五年后还能升级。

对比

候选方案里，Next.js 生态最大，但为静态内容引入 RSC 与缓存模型，概念负担和默认 JS 体积都超出需要；Nuxt 的内容能力接近 Astro，代价是默认 hydration 成本；Hugo 构建最快，但模板表达力和组件化不足，定制设计要写大量手写 JS。

Astro 的匹配点很直接：默认输出零客户端 JS，内容集合用 Zod 做构建期校验，需要交互时再用 islands 局部激活。它对“内容站 + 少量交互”的假设，与这个项目完全重合。

取舍

选择 Astro 7 也意味着接受它的变化：7.0 用 Vite 8、Rust 编译器与 Sätteri 取代了原来的 remark/rehype 管线。对不依赖 remark 插件的项目，这几乎无感；但需要插件时就要显式切回 unified。

另一个约束是工具链：TypeScript 7 已是 npm latest，但类型检查与 lint 生态尚未跟上，所以项目锁定 TypeScript 6.0.3，并把升级条件写进 ADR。

结论

框架选择不是“谁最强”，而是“谁的默认值最接近你的问题”。这个站点的默认值是静态、内容优先、少交互，Astro 7 正好把这些默认值做成了产品。

相关决策记录在 ADR 0001、0004 与 0011。

实现索引

• astro.config.mjs：静态输出、站点与集成配置。
• src/content.config.ts：Content Collections 与 Zod schema。
• src/layouts/BaseLayout.astro：SEO、主题、字体与路由布局。