我从2018年开始构建Jamstack网站。那时，这个宣传词无法抗拒：将所有内容预渲染为静态HTML，从CDN提供服务，并为动态功能添加API。它速度快、安全且托管便宜。Netlify创造了这个术语，Gatsby乘着炒作浪潮，一段时间内，它感觉像是网络开发的未来。

现在是2026年，谈话已经发生了巨大转变。Jamstack Discord服务器变得安静了。Gatsby实际上已经死亡。Netlify裁减了大量员工。然而——这是人们遗漏的部分——Jamstack背后的理念无处不在。只是它们不再带有这个标签了。

那么Jamstack已死了吗？诚实的答案是复杂的，我认为细致的理解比热门观点更重要。

目录

Jamstack在2026年已死？诚实评估哪些改变了

Jamstack真正意味着什么

让我们精确定义，因为许多"Jamstack已死"的论述都源于人们在争论不同的事物。

原始Jamstack（JavaScript、APIs、Markup）有几个核心原则：

  1. 预渲染：在构建时生成HTML，而不是请求时
  2. 解耦：将前端与后端/CMS分离
  3. CDN优先：从边缘提供所有内容
  4. API驱动：通过API和无服务器函数处理动态功能

关键的哲学承诺是构建时间优于请求时间。你在部署期间进行一次繁重工作，每个访问者都获得缓存的结果。

这对博客、营销网站、文档和电子商务产品页面效果很好。对于任何需要个性化、实时数据或内容每几分钟改变一次的内容，效果都很糟糕。

衰退的时间表

以下是Jamstack叙事如何逐步解体的大致过程：

年份 事件 影响
2020 Gatsby融资2800万美元C轮 Jamstack炒作高峰
2021 Next.js引入ISR（增量静态再生成） 模糊了静态和动态之间的界线
2022 React服务器组件公布 朝向服务器渲染的范式转变
2023 Next.js应用路由器稳定，Gatsby使用量直线下降 混合渲染成为默认值
2023 Netlify收购Gatsby，然后基本上搁置它 "纯粹"Jamstack的象征性终结
2024 Astro 4.x获得重大关注，Vercel推动PPR 静态生成以新形式继续存在
2025 Next.js 15发布成熟的RSC模式 服务器优先成为主流默认值
2026 "Jamstack"一词很少出现在职位列表或RFP中 品牌已死，原则依然存在

Gatsby的故事特别值得讲述。在其高峰期，Gatsby拥有数千个插件、庞大的社区和真正的企业采用。到2024年，其npm下载量从峰值下降了80%以上。Netlify的收购没有拯救它——更多是一次悄悄风险关闭的收购雇用。

但将Gatsby的衰退归咎于"Jamstack已死"是错过了重点。Gatsby衰退是因为它有真正的技术问题：荒谬的长构建时间、复杂的数据层（不管你是否想要，GraphQL用于一切）以及一个成为负债的插件生态系统。Next.js击败Gatsby午餐不是因为静态生成是错误的，而是因为Next.js做得更好并提供更多灵活性。

Jamstack永久获胜的地方

以下是我认为人们在"Jamstack已死"叙事上理解错误的地方：核心理念赢得非常彻底，以至于我们停止注意到它们。

解耦架构是默认值

Jamstack最大的胜利是解耦前端现在是任何严肃网络项目的规范。在2018年，你必须为从WordPress或你的CMS中分离前端进行辩论。在2026年，问题不是"我们应该解耦吗？"——而是"哪个无头CMS和哪个前端框架？"

这是一个永久的架构转变。没有人会回到单片PHP模板用于新项目（遗留维护是另一回事）。无头模式——无论你是否将其称为Jamstack——都赢了。

我们在我们的无头CMS开发工作中不断看到这一点。客户不再问"我们应该走向无头吗？"。他们问哪个无头CMS适合他们的内容模型。

CDN优先交付

每个主要框架和托管平台现在都优先考虑边缘交付。Vercel、Cloudflare、Netlify、AWS——他们都假设你的内容应该尽可能接近用户。这是一个Jamstack原则在它成为行业默认值之前。

基于Git的工作流

你的网站从git推送部署，经过CI/CD，在进入生产前登陆预览URL的想法？这在2017年是激进的。现在这是基本要求。每个前端平台都提供这个。Jamstack将其规范化。

静态生成作为一个工具（而不是宗教）

SSG没有死。它成为许多工具中的一个。每个主要框架——Next.js、Astro、Nuxt、SvelteKit——都支持静态生成。区别在于它现在是一个按页面的选择，而不是一个全有或全无的架构。

Jamstack在2026年已死？诚实评估哪些改变了 - 架构

Jamstack失败的地方

诚实意味着也要承认真正的失败。

构建时间是一个真正的问题

大型Jamstack网站的肮脏秘密是构建时间。我在2021年参与了一个拥有40,000个产品页面的项目。完整重建？45分钟。即使有增量构建，任何模式更改都意味着从头开始。当你的内容编辑器必须等待20分钟才能在实时网站上看到更改时，你已经失去了关于开发者体验的论证。

Next.js中的ISR和按需重新验证是对这个问题的直接响应。它们承认预渲染构建时间的所有内容不会扩展到一定点之后。

个性化始终是一个黑客

当每个人看到相同内容时，Jamstack网站很好。一旦你需要用户特定的内容——登录状态、个性化推荐、A/B测试、地理定位定价——你就在与架构作战。客户端提取创建布局转移。边缘中间件增加复杂性。你最终会用额外步骤构建服务器渲染的应用程序。

Jamstack中的"J"变得臃肿

Jamstack网站上的JavaScript包大小变得失控。Gatsby网站常规发送300-500KB的JavaScript用于本质上是博客的东西。静态HTML很快，但然后水合步骤在移动设备上会锁定主线程数秒钟。这是一个自己的目标。

Astro的岛屿架构和服务器组件都是作为对这个JavaScript臃肿问题的直接反应而出现的。

预览和编辑体验受损

习惯于WordPress实时预览的内容编辑在Jamstack上有艰难的时光。你会在CMS中改变标题，触发webhook，等待构建，然后可能看到你的改变。像可视化编辑器和草稿模式这样的工具改进了事物，但体验从未匹配传统CMS现成提供的东西。

服务器组件和混合渲染的崛起

React服务器组件（RSC）代表自SPA时代以来前端架构中最大的哲学转变。而且它们在根本上与纯Jamstack思维相悖。

这是为什么：RSC假设在请求时在服务器上渲染是好的，实际上。而不是预先构建所有内容，你在服务器上渲染组件，将HTML流到客户端，并为不需要交互性的组件发送零JavaScript。

这翻转了Jamstack脚本。而不是"预先构建所有内容并提供静态文件"，它是"按需渲染但聪明地了解哪些需要JavaScript"。

结果不言自明。一个构建完好的RSC应用程序可以匹配或击败静态网站的首字节时间，同时处理个性化、实时数据和动态内容而不需要任何Jamstack变通办法。

// Next.js应用路由器中的服务器组件——没有客户端JS被发送
async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);
  const reviews = await getReviews(product.id);

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* 这个组件在服务器上运行。零KB发送到浏览器。 */}
      <ReviewsList reviews={reviews} />
      {/* 只有这个交互式组件发送JavaScript */}
      <AddToCartButton productId={product.id} />
    </main>
  );
}

心理模式比Jamstack等效物更清晰，在那里你会静态生成产品页面，然后客户端提取评论，然后水合购物车按钮，为每个处理加载状态。

Next.js应用路由器：Jamstack杀手还是其演变？

我会说两者都是。Next.js没有杀死Jamstack——它吸收了它。

Next.js 15在2025年支持你想要的每个渲染策略：

  • 静态生成（SSG）：在构建时渲染的页面
  • 服务器端渲染（SSR）：每个请求渲染的页面
  • 增量静态再生成（ISR）：在时间表上重新验证的静态页面
  • 部分预渲染（PPR）：带有服务器渲染动态孔的静态外壳
  • 客户端渲染：用于纯交互式组件

PPR特别有趣。它预渲染页面的静态外壳（布局、导航、静态内容）并为动态内容留下孔，这些内容在每个请求上被服务器渲染和流入。这就像Jamstack和SSR生了个孩子。

// 使用PPR，静态部分是预渲染的，动态部分流入
import { Suspense } from 'react';

export default function DashboardPage() {
  return (
    <main>
      {/* 这在构建时是预渲染的 */}
      <h1>Your Dashboard</h1>
      <Navigation />
      
      {/* 这在每个请求上动态流入 */}
      <Suspense fallback={<DashboardSkeleton />}>
        <PersonalizedContent />
      </Suspense>
    </main>
  );
}

我们的Next.js开发实践已经严重转向这些混合模式。大多数项目现在在每个页面甚至每个组件的基础上混合使用静态和动态渲染，这在纯Jamstack时代会是异端。

框架级决策已经从"静态或动态"转移到"每一段内容需要什么渲染策略？"这是一个更成熟的对话。

Astro和静态生成文艺复兴

如果你想证明Jamstack活着，Astro是你最好的证据。

Astro采用了Jamstack的最好部分——静态生成、最小JavaScript、默认快速——并构建了一个修复最坏部分的框架。其岛屿架构意味着你默认发送零JavaScript，并仅在你需要它的地方选择交互性。

对于内容丰富的网站，Astro的方法很难击败：

  • 典型的Astro博客页面发送0KB的JavaScript除非你明确添加交互式组件
  • 构建时间很快因为Astro不捆绑完整的React运行时
  • 内容集合提供类型安全的内容层而不需要GraphQL复杂性
  • 你可以使用React、Vue、Svelte或纯HTML组件——选择你的毒药
---
// 这是一个Astro组件。它仅在构建时运行。
const posts = await getCollection('blog');
---

<html>
  <body>
    <h1>Blog</h1>
    {posts.map(post => (
      <article>
        <h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
        <p>{post.data.excerpt}</p>
      </article>
    ))}
    
    <!-- 只有这个岛屿发送JavaScript -->
    <SearchWidget client:load />
  </body>
</html>

Astro的服务器岛屿（在2024年底引入）增加了在其他方面静态页面内拥有动态服务器渲染组件的能力——本质上从静态优先方向到达与Next.js PPR相似的目的地。

在我们的Astro开发工作中，我们越来越多地为营销网站、文档和内容驱动的项目中营销网站、文档和内容驱动项目到达Astro，其中性能是优先事项，交互性需求很少。

功能 Next.js（应用路由器） Astro 5.x 旧Jamstack（Gatsby）
默认渲染 服务器（RSC） 静态（SSG） 静态（SSG）
发送的JavaScript 按组件 默认零 完整React运行时
构建时间（10k页） ~3-5分钟 ~1-2分钟 ~15-30分钟
动态内容 原生（RSC/SSR） 服务器岛屿 客户端提取
个性化 内置 中间件+岛屿 最多是黑客
CMS集成 优秀 优秀 插件依赖
学习曲线 陡峭（RSC模型） 中等 中等-高
最适合 应用+内容混合 内容优先网站 博客（历史上）

无头CMS层：比以往任何时候都强大

这是让我最强硬地对"Jamstack已死"叙事进行反驳的事情：无头CMS市场在蓬勃发展。如果架构真的已死，其内容基础设施不会在繁荣。

无头CMS市场在2024年的价值约为21亿美元，预计到2030年将达到55亿美元（各种分析师估计将CAGR设定在20-25%）。主要参与者都在发布强劲增长：

  • Contentful继续主导企业无头CMS，在2025年具有改进的可组合性功能
  • Sanity以其实时协作编辑和GROQ查询语言快速增长
  • Storyblok使用其视觉编辑器在一个强大的利基中进行了雕刻，解决了早期Jamstack困扰的预览问题
  • Payload CMS（开源、自托管）获得了希望完全控制的开发者的严肃关注
  • Hygraph（前身为GraphCMS）继续为GraphQL优先团队服务

无头CMS不在乎你的前端是否使用静态生成、服务器组件或信鸽。它通过API提供结构化内容。就这样。渲染策略是你的前端的问题。

这种解耦是最耐用的Jamstack遗产。内容层和表示层分开不是趋势——它是一个在品牌死亡中幸存下来的架构原则。

2026年现代架构实际上是什么样的

那么如果我们不称之为Jamstack，我们叫什么大多数现代网站的构建方式？我在对话中一直使用"无头混合"，尽管我不喜欢它。该行业尚未确定术语，这可能没关系。我们不需要营销标签来代表良好的架构。

以下是典型项目在2026年的样子：

内容层：无头CMS（Sanity、Contentful、Payload、Storyblok——取决于需求和预算）

前端框架：Next.js用于任何具有应用类功能或复杂交互的东西。Astro用于内容优先网站。如果团队有这些偏好，则为SvelteKit或Nuxt。

渲染策略：混合。营销页面是静态生成的。产品页面使用ISR或PPR。用户仪表板使用服务器端渲染。交互式小部件使用客户端渲染。框架处理所有这些。

托管：边缘优先平台。Vercel、Cloudflare Pages、Netlify或AWS（CloudFront + Lambda@Edge）取决于规模和预算。

构建过程：基于Git的CI/CD与预览部署。来自CMS的webhook触发的重新验证。

如果你眯眼看，这看起来很像Jamstack但更灵活。这就是重点。

我们在无头CMS开发合作期间帮助客户做出的架构决策反映了这种混合现实。没有单一的大小适合所有渲染策略。正确的答案取决于内容量、个性化需求、编辑工作流要求和预算。如果你为自己的项目权衡这些权衡，我们很乐意讨论。

常见问题

Jamstack在2026年已死了吗？ 品牌实际上已经死亡——你在许多职位列表或RFP中都看不到"Jamstack"。但核心架构原则（解耦前端、CDN交付、API驱动的内容、基于git的工作流）比以往任何时候都更普遍。它们已被吸收到主流网络开发中，以至于它们不需要单独的标签。Gatsby特别是死了。哲学持续存在。

什么取代了Jamstack？ 像Next.js（使用应用路由器和RSC）、Astro、Nuxt 3和SvelteKit这样的混合渲染框架已经取代了纯静态生成方法。这些框架让你为每个页面甚至每个组件选择正确的渲染策略——静态、服务器渲染或客户端。无头架构模式（解耦CMS+前端框架+边缘托管）仍然是标准；它只是不再携带Jamstack标签。

在2026年静态网站生成仍然相关吗？ 绝对。SSG仍然是不经常改变的内容和不需要个性化的内容的最佳选择——博客、文档、营销页面、登陆页面。Astro已成为静态优先网站的首选框架。Next.js和Nuxt仍然支持SSG作为许多渲染选项中的一个。改变的是SSG现在是一个你适当到达的工具，而不是整个架构哲学。

Gatsby发生了什么？ Gatsby在2023年初被Netlify收购，并且实际上已停止使用。其最后有意义的更新是在2023年。生态系统崩溃是因为插件维护者继续进行，社区迁移到Next.js、Astro和其他框架。Gatsby的核心问题——过度的构建时间、强制的GraphQL数据层、重的JavaScript包和复杂的插件系统——从未得到充分解决。

我在2026年仍然应该使用无头CMS吗？ 是的，无头CMS平台的市场比以往任何时候都强大。Contentful、Sanity、Storyblok、Payload CMS和其他已经成熟了显著。无头CMS解耦是最耐用的Jamstack原则。它让你独立选择前端，跨渠道重用内容并避免对单片平台的供应商锁定。除非你构建个人博客（markdown文件很好），无头CMS是值得投资的。

React服务器组件如何改变Jamstack等式？ RSC从根本上改变了默认值从"在构建时预渲染"到"在请求时在服务器上渲染"。服务器组件在服务器上运行，向浏览器发送零JavaScript，并可以直接访问数据库和API。这消除了许多Jamstack对动态内容需要的变通办法——不再需要客户端提取、加载旋转器或服务器本可以包含在初始响应中的数据的布局转移。RSC使服务器渲染感觉与静态生成一样符合人体工程学。

从Jamstack设置迁移到Next.js应用路由器是否值得？ 这取决于你解决的问题。如果你当前的静态设置处理你的需求——你的内容大多是静态的、构建速度足够快，你不需要个性化——没有迫切的理由迁移。如果你在与构建时间作战、添加越来越复杂的客户端数据提取或与预览工作流搏斗，应用路由器的混合渲染模型可能值得迁移成本。RSC和应用路由器的学习曲线是真实的，所以将其纳入你的决策。

2026年新内容网站的最佳框架是什么？ 对于纯内容网站（博客、文档、营销），Astro很难击败——默认零JavaScript、快速构建、优秀的DX和优秀的无头CMS集成。对于混合内容和应用功能的网站（电子商务、用户账户、仪表板），Next.js为你提供最灵活的混合渲染选项。如果你的团队更喜欢Vue，Nuxt 3提供与Next.js相似的功能。这三者之间没有错误的答案；选择取决于你的团队的专业知识和你的项目的特定需求。