静态网站回潮时，我为什么选择 Astro

最近 Cloudflare 在 X 上问了一个问题：

Static sites are having a renaissance. What is your favorite static site generator right now and why do you prefer it?

评论区里 Astro 的名字出现得很频繁。

这和我最近一段时间的感受很接近。过去一年，我在不少新项目里使用 Astro，主要是官网、产品介绍页、内容站这类偏静态的网站。这个博客也从 Hexo 迁移到了基于 Astro 的新系统。

我越来越觉得，静态网站并没有过时。相反，它在重新变得重要。

只不过这一次的静态网站，不再是早年那种模板、插件和主题拼出来的站点，而是用现代 JavaScript 工具链开发，最终交付标准 HTML、CSS 和少量必要 JavaScript 的网站。

Astro 刚好踩中了这个位置。

English version: Static Sites Are Having a Renaissance. Here Is Why I Chose Astro

静态网站为什么又值得重视

静态网站的优势一直都在：快、稳定、便宜、容易缓存、部署简单、安全面小。

如果一个页面的主要任务是展示内容，比如博客文章、官网首页、产品介绍、文档、作品集、活动页，那么最理想的交付物本来就应该是 HTML 和 CSS。用户点开页面时，不应该先下载一大包 JavaScript，再等浏览器在客户端把内容组装出来。

过去几年，前端社区习惯了用构建 Web App 的方式构建一切。React、Vue、Next.js、Nuxt、SvelteKit 都很强，但这些框架的心智模型经常从“应用”开始：状态、路由、数据请求、hydration、客户端交互、服务端渲染、缓存、边缘运行时。

这些能力对复杂应用很重要。但对很多内容型网站来说，它们不是起点，而是额外成本。

静态网站回潮，本质上不是怀旧，而是一个更务实的判断：如果网站主要是内容，那就应该优先把内容直接交付给浏览器。

Astro 的核心吸引力

Astro 官方文档对自己的定位很明确：它是面向内容驱动网站的 Web 框架，适合博客、营销站、电商内容页、文档、作品集、社区站等场景。

这句话很重要。Astro 不是试图覆盖所有 Web 形态，然后顺便支持静态导出。它一开始就把内容型网站作为核心目标。

对我来说，Astro 最吸引人的地方是这种组合：

• 编写时是现代前端体验，可以用组件、TypeScript、Vite、Markdown、MDX、npm 生态。
• 构建后是性能很好的静态产物，HTML、CSS 都是标准的。
• JavaScript 默认不是页面的基础设施，而是交互增强。

这和传统静态站点生成器的差别很明显。Hexo、Jekyll、Hugo 这些工具都能把 Markdown 变成静态 HTML，但它们的开发体验更接近“内容系统”或“模板系统”。Astro 则更像现代前端工程，但产物又没有被前端应用的复杂度拖住。

这个平衡点很舒服。

默认少发 JavaScript

Astro 最常被提到的是岛屿架构。

在 Astro 的解释里，页面的大部分内容会渲染成静态 HTML，只有需要交互或个性化的区域才作为 JavaScript 岛屿运行。默认情况下，Astro 组件会输出 HTML 和 CSS，不会把客户端运行时一起发给浏览器。

这件事的价值不只是“性能更好”。

它更像是把前端开发的默认值改了回来：页面应该先是文档，然后才在必要处变成应用。

我现在使用 Astro 时，其实很少用 React、Vue 这些框架组件，也还没有大量使用岛屿能力。很多页面就是 Markdown、Astro 组件、CSS 和少量脚本。但这并不影响 Astro 的价值。恰恰相反，Astro 对纯静态页面很友好，说明它的默认模型足够正确。

在很多官网项目里，真正需要客户端 JavaScript 的地方很少：导航菜单、主题切换、表单校验、图片轮播、搜索框、少量动画。把整站做成一个客户端应用，并不总是合理。

Astro 的好处在于，它不会因为页面上有一个交互组件，就要求整页都背上应用框架的成本。

内容是第一等公民

Astro 另一个重要长处是内容能力。

Content Collections 让 Markdown、MDX、JSON 等内容可以有 schema、类型提示和校验。对博客、文档、官网、产品内容页来说，这比单纯遍历文件目录可靠得多。

一个内容型网站长期维护时，真正麻烦的通常不是把页面渲染出来，而是这些事情：

• 文章字段是否完整。
• 标签、分类、日期、摘要是否规范。
• 多语言内容如何组织。
• RSS、sitemap、搜索索引如何生成。
• 旧链接如何兼容。
• 图片、代码块、外链如何长期可维护。

Astro 不能自动解决所有内容治理问题，但它给了一个更适合现代工程的基础。内容不是模板系统的附属品，而是可以被类型系统、构建流程和组件系统共同处理的输入。

这个博客从 Hexo 迁移出来时，我最看重的也是这一点。Markdown 仍然是内容源，但围绕 Markdown 的构建、路由、feed、搜索、llms.txt、多语言和部署，可以用更现代的方式组织。

静态优先，但不是只能静态

Astro 很容易被理解成“静态站点生成器”，但它已经不只是传统意义上的 SSG。

Astro 6.0 发布于 2026 年 3 月，带来了内置 Fonts API、稳定的 Content Security Policy API、Live Content Collections，并且重构了 dev server 和构建流水线。Live Content Collections 让外部 CMS 或 API 内容可以在请求时获取，不必每次内容变化都重新构建。

这说明 Astro 的演进方向并不是停留在“把 Markdown 编译成 HTML”。它仍然静态优先，但保留了向动态内容、服务端渲染、边缘运行时扩展的路径。

这个方向对内容型网站很关键。

因为很多网站一开始都是静态的，后来会慢慢长出一些动态需求：订阅表单、用户状态、A/B 测试、个性化推荐、CMS 实时更新、受保护内容、局部后台数据。直接从全栈应用框架开始，早期成本偏高；只选一个纯静态生成器，后续扩展又可能受限。

Astro 的位置介于两者之间：先把静态页面做好，再让动态能力按需出现。

Cloudflare 的信号

还有一个值得关注的变化是 Astro 和 Cloudflare 的关系。

2026 年 1 月，Cloudflare 发布了 Astro is joining Cloudflare：Astro Technology Company 加入 Cloudflare，Astro 继续保持开源、MIT 许可、公开路线图和开放治理，也继续强调跨平台部署。

这件事对 Astro 的长期价值是加分项。

内容型网站和 Cloudflare 的基础设施天然匹配。静态资源、CDN、边缘缓存、Workers、Pages、R2、D1，这些能力都围绕一个方向展开：让网站更快、更靠近用户、更容易部署。Astro 如果继续强化 Cloudflare 运行时支持，同时保持平台无关，对开发者来说是一个比较好的状态。

当然，框架加入大公司并不自动等于更好。开源项目最重要的仍然是治理、社区、路线图和实际使用体验。但 Cloudflare 选择 Astro，至少说明内容型网站、静态优先和边缘部署这条路线并不边缘。

和其他方案怎么选

Astro 是不是现在做静态网站的第一选择？

我的答案是：如果是内容型网站，并且开发者主要在 JavaScript / TypeScript 生态里工作，Astro 可以作为第一选择。但它不是所有静态网站的唯一最优解。

Hugo 仍然非常强。它构建速度快，单文件二进制，适合大量 Markdown 内容和很少前端定制的站点。如果团队不需要现代前端组件，只想稳定、快速、长期生成静态页面，Hugo 很有竞争力。

Eleventy 更朴素，也更接近传统模板系统。它的框架感更弱，适合喜欢直接控制 HTML 输出、对前端运行时保持距离的开发者。

VitePress 和 Docusaurus 更适合文档站。版本管理、侧边栏、文档导航、搜索、代码块、主题约定，这些能力在文档场景里很重要。做产品文档时，选专门的文档框架通常更省心。

Next.js、Nuxt、SvelteKit 这类框架也能做静态导出，但它们更适合应用型网站。如果项目有登录态、后台、复杂表单、实时数据、强交互、服务端数据流，直接使用应用框架会更自然。静态导出是它们的能力之一，但不是最清晰的心智起点。

Hexo、Jekyll 这类传统博客系统也不是不能用。它们的优势是成熟、稳定、主题多、迁移路径清楚。只是对习惯现代前端工程的人来说，Astro 的开发体验、组件能力和扩展空间会更顺手。

所以选择标准不应该是“哪个框架最火”，而应该是：

• 如果主要是内容，优先 Astro、Hugo、Eleventy。
• 如果主要是文档，优先 VitePress、Docusaurus、Starlight。
• 如果主要是应用，优先 Next.js、Nuxt、SvelteKit。
• 如果主要是博客，并且希望现代前端体验和静态产物兼得，Astro 很值得优先考虑。

Astro 不适合什么

Astro 的优势来自内容优先，也意味着它不是所有场景的最佳选择。

如果一个项目本质上是后台系统、SaaS 应用、协同工具、复杂编辑器、数据看板，或者从首页开始就需要大量客户端状态，那么 Astro 未必是最自然的选择。它能接入 React、Vue、Svelte，也能做服务端渲染，但这类项目的复杂度通常不在“页面静态输出”，而在应用状态、数据流、权限、表单、实时协作和交互结构。

这时 Next.js、Nuxt、SvelteKit，甚至传统后端全栈框架，可能更适合。

Astro 的一个常见误区，是把它当成“更快的 React 框架”。我觉得这种理解并不准确。Astro 更像是一个内容网站框架。它允许在需要时嵌入 React，但它的核心价值不是让 React 更快，而是让多数页面不必先变成 React 应用。

这个区别很重要。

我为什么选择 Astro

从 Hexo 到 Astro，我最大的感受不是“换了一个更潮的工具”，而是静态网站的工程模型变清楚了。

以前做静态博客，常见感受是内容系统和前端工程之间有一道墙。写文章、调主题、改模板、加插件、处理构建，经常像是在一个偏封闭的生态里工作。

Astro 的感觉不同。它仍然尊重静态网站的本质，但把开发体验带回现代前端：

• 页面是组件。
• 样式可以局部组织。
• Markdown 是内容源。
• 构建由 Vite 驱动。
• 需要交互时再引入客户端 JavaScript。
• 需要动态能力时再接入服务端或边缘运行时。

这也是我在新官网项目里反复选择 Astro 的原因。

官网和博客最重要的不是“技术栈看起来完整”，而是用户打开得快、搜索引擎能读懂、内容长期可维护、部署链路简单、迁移成本可控。

Astro 在这些点上给出的答案很直接。

静态网站不是退回去

静态网站的回潮，不是前端工程倒退。

恰恰相反，它更像是前端社区在经历了多年应用框架膨胀之后，重新认识到 Web 的基础能力本来就很强。HTML 可以表达内容，CSS 可以完成大量视觉，浏览器可以直接渲染页面，CDN 可以把内容分发到全球。

JavaScript 当然重要，但它不应该自动成为每个页面的地基。

Astro 的价值就在这里：它没有否定现代前端，也没有把所有东西都推向客户端应用。它只是给了一个更合理的默认值：

先输出网页，再按需增强。

对内容型静态网站来说，这几乎就是最朴素、也最有效的工程原则。

所以如果今天要做一个博客、官网、作品集、产品介绍页、营销站或者内容门户，我会优先考虑 Astro。不是因为它最流行，而是因为它的默认取舍和这类网站的真实需求一致。

静态网站并没有消失。它只是终于等到了更适合现代开发者的工具。