2026年Jamstack真的已死吗？炒作消退后发生了什么

你的部署完成，12,000个静态页面被推送到CDN。没有服务器启动。没有数据库查询在请求中间触发。它很快，版本受控，每月只需花费$19来托管——这正是Netlify在2019年创造"Jamstack"术语时向你兜售的承诺。但到了2026年，没有人再这样称呼它了。这个架构活了下来。但品牌死了。你看到的不是死亡——这是一次变异。Gatsby陷入维护模式。Next.js吸收了生态的一半，并转向React Server Components。Astro推出了岛屿架构，并将静态生成称为"明显的默认值"。你所依赖的模式分裂成了五种相互竞争的哲学，每一种都声称通过不成为Jamstack来更好地实现Jamstack。

现在是2026年，对话已经发生了巨大变化。Jamstack Discord服务器变得更安静了。Gatsby实际上已经死亡。Netlify裁减了相当一部分员工。然而——这是人们忽略的部分——Jamstack背后的想法无处不在。它们只是不再带着这个标签了。

那么Jamstack真的死了吗？诚实的答案很复杂，我认为细微差别比夸张的观点更重要。

目录

• Jamstack实际上意味着什么
• 衰退的时间表
• Jamstack永久赢得的地方
• Jamstack失败的地方
• Server Components和混合渲染的兴起
• Next.js App Router：Jamstack的杀手还是其演变？
• Astro与静态生成复兴
• Headless CMS层：比以往任何时候都更强大
• 现代架构在2026年的实际样子
• 常见问题

Jamstack实际上意味着什么

让我们精确定义，因为很多"Jamstack已死"的讨论都是因为人们在争论不同的东西。

最初的Jamstack（JavaScript、APIs、Markup）有几个核心原则：

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

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

这对博客、营销网站、文档和电商产品页面非常有效。但对于任何需要个性化、实时数据或每几分钟就改变的内容的应用程序，它的表现就很糟糕。

衰退的时间表

以下是Jamstack叙事大致如何崩溃的过程：

年份	事件	影响
2020	Gatsby融资$28M C轮	Jamstack热度顶峰
2021	Next.js引入ISR（增量静态再生成）	模糊了静态和动态之间的界限
2022	React Server Components宣布	向服务器渲染的范式转变
2023	Next.js App Router稳定，Gatsby使用量大幅下降	混合渲染成为默认值
2023	Netlify收购Gatsby，然后基本上搁置了它	"纯"Jamstack的象征性终结
2024	Astro 4.x获得重大关注，Vercel推出PPR	静态生成以新形式继续存在
2025	Next.js 15发布成熟的RSC模式	Server-first成为主流默认值
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年，问题不是"我们应该解耦吗？"——而是"我们选择哪个headless CMS和哪个前端框架？"

这是一个永久的架构转变。没有人会再为新项目回到整体PHP模板（遗留维护是另一回事）。Headless模式——无论你称之为Jamstack与否——已经赢了。

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

CDN优先的交付

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

基于Git的工作流

你的网站从git推送部署、经过CI/CD，在进入生产环境前进入预览URL的想法？那在2017年很激进。现在是基本要求。每个前端平台都提供这个。Jamstack使其成为常规化。

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

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

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提供的开箱即用体验。

Server Components和混合渲染的兴起

React Server Components（RSC）代表自SPA时代以来前端架构最大的哲学转变。它们在根本上与纯Jamstack思想相悖。

原因是：RSC假设在请求时在服务器上渲染是好事，实际上。与预构建一切不同，你在服务器上渲染组件，将HTML流发送到客户端，对不需要交互性的组件发送零JavaScript。

这颠覆了Jamstack脚本。与其说"提前构建一切并提供静态文件"，不如说"按需渲染但要聪明地对待什么需要JavaScript"。

结果不言自明。一个设计良好的RSC应用程序可以匹配或超过静态网站的首字节时间（TTFB），同时处理个性化、实时数据和动态内容，无需任何Jamstack的变通办法。

// Next.js App Router中的服务器组件——没有客户端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等价物更清洁，在Jamstack中，你会静态生成产品页面，然后客户端获取评论，然后水合购物车按钮，为每个处理加载状态。

Next.js App Router：Jamstack的杀手还是其演变？

我认为两者都有。Next.js没有杀死Jamstack——它吸收了它。

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

• 静态生成（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运行时
• Content Collections提供了没有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（App Router）	Astro 5.x	老Jamstack（Gatsby）
默认渲染	服务器（RSC）	静态（SSG）	静态（SSG）
运送的JavaScript	每组件	默认零	完整React运行时
构建时间（10k页）	~3-5分钟	~1-2分钟	~15-30分钟
动态内容	原生（RSC/SSR）	服务器岛屿	客户端获取
个性化	内置	中间件+岛屿	充其量是黑客
CMS集成	优秀	优秀	依赖插件
学习曲线	陡峭（RSC模型）	中等	中等-高
最适合	应用+内容混合	内容优先网站	博客（历史上）

Headless CMS层：比以往任何时候都更强大

让我最反对"Jamstack已死"叙事的是：headless CMS市场繁荣。如果架构真正死了，其内容基础设施不会蓬勃发展。

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

• Contentful继续主导企业headless CMS，在2025年改进了可组合性功能
• Sanity以其实时协作编辑和GROQ查询语言迅速增长
• Storyblok通过其可视化编辑器开创了一个强大的利基，解决了Jamstack早期困扰的预览问题
• Payload CMS（开源、自托管）以开发人员想要完全控制获得了真正的关注
• Hygraph（前身为GraphCMS）继续服务GraphQL优先的团队

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

这种解耦是最持久的Jamstack遗产。内容层和呈现层的分离不是一个趋势——这是一个存活了品牌死亡的架构原则。

现代架构在2026年的实际样子

所以如果我们不称之为Jamstack，我们怎么称呼大多数现代网站的构建方式呢？我在对话中一直使用"headless混合"，尽管我不喜欢它。业界还没有就一个术语达成共识，这可能没关系。我们不需要一个好架构的营销标签。

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

内容层：一个headless 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。那才是重点。

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

常见问题

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

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

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

Gatsby发生了什么？ Gatsby在2023年初被Netlify收购，此后已被有效停用。其最后一次有意义的更新是在2023年。随着插件维护者转向，社区迁移到Next.js、Astro和其他框架，生态系统崩溃了。Gatsby的核心问题——过度构建时间、强制的GraphQL数据层、沉重的JavaScript包和复杂的插件系统——从未得到充分解决。

在2026年我还应该使用headless CMS吗？ 是的，headless CMS平台的市场比以往任何时候都更强。Contentful、Sanity、Storyblok、Payload CMS等都已经成熟了很多。Headless CMS解耦是最持久的Jamstack原则。它让你独立选择前端，在渠道中重用内容，并避免绑定到整体平台。除非你在构建个人博客（其中markdown文件很好），否则headless CMS值得投资。

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

从Jamstack设置迁移到Next.js App Router值得吗？ 这取决于你要解决什么问题。如果你当前的静态设置处理你的需求——你的内容基本是静态的、构建够快、你不需要个性化——没有紧急的理由迁移。如果你在与构建时间作斗争、添加越来越复杂的客户端数据获取、或在预览工作流中苦苦挣扎，App Router的混合渲染模型可能值得迁移成本。对RSC和App Router的学习曲线是真实的，所以在你的决定中考虑这一点。

2026年新建内容网站的最好框架是什么？ 对于纯内容网站（博客、文档、营销），Astro很难被击败——默认零JavaScript、快速构建、优秀的开发者体验和出色的headless CMS集成。对于混合内容和应用功能的网站（电商、用户账户、仪表板），Next.js凭借其混合渲染选项提供了最多的灵活性。如果你的团队更喜欢Vue，Nuxt 3提供了与Next.js相似的功能。这三者中没有错误的答案；选择取决于你的团队的专业知识和你的项目的具体需求。