为 JavaScript 项目选择静态站点生成器
选错静态站点生成器付出的代价远不止时间。它会影响你的部署模式、运行时复杂度，以及最终呈现给用户的 JavaScript 体量。到了 2026 年，可选项已经显著成熟，但它们之间的差异也朝着关键方向分化。下面是思考这一选择的方法。
关键要点
- 真正的 SSG（如 Astro 6 和 Eleventy 3）与混合框架（如 Next.js、Nuxt 和 SvelteKit）有本质区别——将它们等同看待会导致糟糕的架构决策。
- 凭借岛屿架构（islands architecture）和多框架组件支持，Astro 6 是 2026 年内容密集型站点最强的默认选项之一。
- Next.js 16 稳定的 Adapter API 和 OpenNext 让多平台部署变得可行，但即便仅用于大多为静态的输出，它仍然比 Astro 或 Eleventy 带来更多框架复杂度。
- 选择工具时，应从渲染需求和基础设施需求出发，而非框架的流行度。
并非所有”SSG”都是同一类东西
在比较工具之前，先把分类讲清楚会有帮助。Astro 6 和 Eleventy 3 是真正以内容为核心的静态站点生成器。它们旨在产出最少的 JavaScript，并优先采用构建时渲染。
Next.js 16、Nuxt 4 和 SvelteKit 是混合框架，它们支持静态输出，但并非主要面向 SSG 场景。它们默认的心智模型是服务端渲染或边缘部署的应用程序。纯粹用它们做静态生成是可行的，但相比真正以静态为先的工具，你依然背负了大量额外的框架复杂度。
将这两类视为等同，会导致糟糕的决策。
逐个框架解析
Astro 6 已经成为内容密集型站点和文档门户最强的选项之一。它的岛屿架构默认零 JavaScript，按组件粒度选择是否启用交互。Astro 6 支持在同一项目中混用 React、Vue、Svelte 和 Solid 组件。如果你主要关心内容性能，并希望保留框架灵活性，那么 Astro 是 2026 年最明确的推荐。
Eleventy 3 仍是追求简洁、可控、且不希望承担框架开销时的合适工具。它支持多种模板语言，构建速度快，输出干净的 HTML。Eleventy 3 增加了完整的 ESM 支持和异步配置。它没有过时——它是有意保持极简，而这恰好是某些项目所需要的。
Next.js 16 引入了稳定的 Adapter API，对多平台部署支持有实质性改进，其中包括 OpenNext，它让 Next.js 能部署到 Cloudflare、AWS Lambda 等非 Vercel 运行时上。如果团队以 React 为本，项目混合了静态页面、API 路由和服务端组件，那么 Next.js 仍是最强大的选项。只是要清醒地认识到：你运行的是一个完整框架，而不是纯 SSG。
Nuxt 4 为 Vue 生态带来了同样的混合能力。通过 nuxt generate 的静态生成稳定可靠，并能与无头 CMS 平台无缝集成。对于构建营销站点或内容驱动型应用、且后续可能需要服务端能力的 Vue 团队来说，Nuxt 4 是天然之选。
SvelteKit 配合 adapter-static 适合构建以静态为主的 Svelte 团队项目。该适配器会产出完全静态的输出，但框架本身假设的是服务端优先模型，因此某些特性在纯静态模式下需要绕行处理。如果团队已熟悉 Svelte 且项目较轻量，它是不错的选择。
Gatsby 仍然存在，并在被 Netlify 收购后持续更新，但曾使其成为默认 React SSG 的生态势能，已大量转移到 Astro 和 Next.js 上。Gatsby 的 GraphQL 数据层对复杂内容网格仍有用，但它已不再是新 React 静态项目的显然起点。
Docusaurus 是大型团队或开源项目文档站点的实际默认选项。它基于 React，由 Meta 维护，内置版本管理、i18n 和搜索。对于个人开发者或小团队构建文档，Astro 的 Starlight 主题是值得考虑的更轻量替代方案。
一个简单的决策框架
| 项目类型 | 推荐工具 |
|---|---|
| 内容站点、博客、营销页 | Astro 6 |
| 文档门户 | Docusaurus 或 Astro Starlight |
| 低 JS、模板驱动的站点 | Eleventy 3 |
| 需要静态 + 服务端能力的 React 应用 | Next.js 16 + OpenNext |
| 需要混合渲染的 Vue 应用 | Nuxt 4 |
| Svelte 团队、轻量站点 | SvelteKit adapter-static |
Discover how at OpenReplay.com.
部署与托管考量
你的托管目标很关键。Astro 和 Eleventy 产出的是纯静态文件，可部署到任何地方——Netlify、Cloudflare Pages、S3 或自有服务器。Next.js 16 配合 OpenNext 在非 Vercel 部署上已有显著改善，但仍比真正的静态输出需要更多配置。Nuxt 和 SvelteKit 也有类似考量。
如果你的目标是 Cloudflare Pages 或需要边缘原生部署，Astro 和 Eleventy 阻力最小。如果你需要 ISR 或服务端组件，那无论选哪个，你都已进入混合框架的领域。
应该首先问的正确问题
不要从”哪个框架最流行”开始。请先问：这个项目在运行时实际需要多少 JavaScript？我愿意管理多少服务端基础设施？
如果答案是”最少的 JavaScript，无服务端”，那么 Astro 6 或 Eleventy 3 会比一个被配置成 SSG 的混合框架更适合你。如果答案涉及动态路由、鉴权或个性化，那么 Next.js 16 或 Nuxt 4 让你有成长空间，无需在项目中途更换工具。
结语
最适合你项目的 SSG 是与渲染需求匹配的那一个——而不是 GitHub 星标最多的那一个。诚实评估项目真正需要的交互量、服务端逻辑和基础设施量，然后选择能满足这些需求的最轻量工具。内容站点不需要混合框架，带鉴权和动态路由的应用也无法靠纯 SSG 服务好。让工具匹配工作负载，你就能省下数月与自家技术栈搏斗的时间。
常见问题
基本可以。Markdown 和 MDX 内容通常只需极少改动即可迁移，因为 Astro 原生支持二者。更难的工作是用 Astro 的内容集合（content collections）替换 Gatsby 的 GraphQL 数据层，并将 React 页面组件重写为 Astro 组件。请计划渐进式迁移，而非一次性重写，并预期插件替换会耗时最长。
通常是的。即便只需要大部分静态的输出，Next.js 仍会带来更多框架复杂度，这意味着更大的包体和不必要的构建复杂度。对于没有鉴权、动态路由或服务端逻辑的博客或营销站点，Astro 6 或 Eleventy 3 通常能以更少的配置和更简单的部署，产出更快的站点。
可以。Astro 直接支持 React、Vue、Svelte 和 Solid 组件，你可以将现有的 React 组件投入 Astro 页面，只需极少改动。关键的转变是决定哪些组件需要使用 client:load 或 client:visible 等指令进行客户端 hydration。没有这些指令的组件会在构建时渲染为静态 HTML，零 JavaScript 输出。
比以前少了。Next.js 16 中稳定的 Adapter API 以及 OpenNext 等项目，已让 Next.js 在 Cloudflare、AWS Lambda 及其他运行时上的部署变得切实可行。话虽如此，某些 Vercel 专属特性仍然在 Vercel 上表现最佳。如果平台独立性是硬性要求，请在项目早期就对照适配器支持情况评估你所使用的特性。
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.
