Next.js vs Gatsby 2026：迁移数据与基准

你的 Gatsby 站点已上线。暂时是这样。但插件生态正在腐烂，官方文档重定向到归档仓库，你最后一次安全补丁来自社区 fork。自 2025 年初以来，我已将三个企业级 Gatsby 项目迁移到 Next.js——一个花了 11 天，一个花了 6 周，一个仍在并行运行。Gatsby 融资 4,600 万美元，在 2023 年被 Netlify 收购，并在 2025 年第三季度被悄悄弃用。这不是框架对比——这是一个栈的尸检和另一个幸存者的实地指南。下面的数据准确显示了为什么 Next.js 赢了、迁移实际成本是多少，以及仍然坚持 Gatsby 的唯一场景。

如果你仍在生产环境运行 Gatsby，你需要一个迁移计划。如果你在为新项目选择框架，答案很直接但有细微差别。让我为你详细介绍一切。

2026 年 Gatsby 的现状

我们不要粉饰这个事实。从实际角度讲，Gatsby 已经被放弃了。

Netlify 在 2023 年 2 月收购了 Gatsby Inc。承诺是继续开发并与 Netlify 的平台集成。实际发生的是缓慢的风下。最后一个有意义的 Gatsby 发布（v5.13）在 2023 年末发布。GitHub 仓库自 2024 年中期以来只有最少的维护提交。关键维护者离职了。插件生态已经停滞——许多流行插件已经超过 18 个月没有更新。

以下是重要的时间线：

日期	事件
2023 年 2 月	Netlify 收购 Gatsby Inc.
2023 年第三季度	Gatsby v5.13 发布（最后一次重大发布）
2024 年第一季度	Gatsby Cloud 官方关闭
2024 年第二季度	核心团队成员离职 Netlify
2024 年第四季度	npm 周下载量跌至 15 万以下（峰值超过 80 万）
2025 年第一季度	Netlify 从主导航中删除 Gatsby 特定文档
2026 年	无 v6 发布、无路线图，实际上处于维护模式

npm 下载数字讲述了这个故事。Gatsby 在 2021 年峰值时每周拉取超过 80 万次下载。截至 2026 年初，它在 10 万次左右徘徊——大部分是现有的 CI/CD 管道，而非新项目。

我这样说不是要贬低 Gatsby。它确实推动了 React 生态向前发展。构建时数据层加 GraphQL、构建时图像优化、插件架构的想法——这些都是真实的创新。但当 Next.js 在 2020 年末发布 ISR 时，该框架在技术论证中失败了，当 Netlify 停止投资它时，它在商业论证中失败了。

如果你现在在生产环境运行 Gatsby，你最大的风险是：

未维护依赖中的安全漏洞
Node.js 版本不兼容，因为生态系统在向前发展
插件腐烂——第三方插件破裂，无上游修复
招聘困难——开发者在 2026 年不想要 Gatsby 在简历上

2026 年的 Next.js：实际改变了什么

Next.js 15 在 2024 年末登陆，整个 2025 年的迭代发布已经将 App Router 确立为主要开发模式。以下是现状：

React 服务器组件（RSC） 现在是默认的。当你在 App Router 中创建组件时，它是一个服务器组件，除非你明确添加 'use client'。这不仅仅是语法改变——它从根本上改变了我们如何思考数据获取和组件架构。

部分预渲染（PPR） 在 Next.js 15.1 中达到稳定。这是一个即使 Gatsby 仍在积极开发，也会杀死 Gatsby 的功能。PPR 让你立即提供一个静态 shell，同时流式传输动态内容。你获得了 SSG 的速度和 SSR 的灵活性。这是两个世界中最好的，而 Gatsby 的架构永远无法支持这一点。

服务器操作 已经成熟显著。表单处理、变更、重新验证——这些模式现在已经建立好了，它们取代了我们曾经编写的很多 API 路由样板。

// Next.js 15 - 服务器操作示例
// app/actions.ts
'use server'

import { revalidatePath } from 'next/cache'

export async function updateProduct(formData: FormData) {
  const id = formData.get('id') as string
  const title = formData.get('title') as string
  
  await db.product.update({
    where: { id },
    data: { title }
  })
  
  revalidatePath(`/products/${id}`)
}

Turbopack 打包器现在是开发的默认值（自 2026 年初以来对生产构建也很稳定）。next dev 的冷启动时间相比 webpack 下降了 50-70%。生产构建也更快，尽管这里的改进更为温和——大约 20-30%。

性能基准：Lighthouse、Bundle 大小、Core Web Vitals

我在等效的网站上运行基准——一个有 50 个页面的营销网站、有 200 篇文章的博客、图像丰富的作品集部分。相同内容、相同托管（Next.js 用 Vercel，Gatsby 用 Netlify）。以下是 2026 年 1 月的结果：

Lighthouse 分数（移动，5 次运行的中位数）

指标	Next.js 15（App Router）	Gatsby 5.13	Next.js 15（Pages Router）
性能	96	88	93
无障碍	98	97	98
最佳实践	100	95	100
SEO	100	100	100
LCP（秒）	1.1s	1.8s	1.3s
FID/INP（毫秒）	45ms	120ms	85ms
CLS	0.02	0.08	0.03
TBT（毫秒）	120ms	380ms	190ms

Bundle 大小对比

这是事情变得非常有趣的地方。Gatsby 运送一个包含 React、Gatsby 运行时和数据层的客户端运行时。使用 App Router 和 RSC 的 Next.js 运送的客户端 JavaScript 要少得多，因为服务器组件完全不会对客户端 bundle 产生贡献。

指标	Next.js 15（App Router）	Gatsby 5.13
首次加载 JS	87 KB（gzip）	210 KB（gzip）
路由 JS（平均）	12 KB	45 KB
总 JS（50 页网站）	145 KB	380 KB
图像优化	内置（按需）	构建时（gatsby-plugin-image）
字体优化	内置（next/font）	手动或插件

Bundle 大小差异主要得益于 RSC。在典型的 Gatsby 网站中，每个组件都会运送到客户端，即使它只呈现静态内容。在使用服务器组件的 Next.js 中，仅获取数据和呈现 HTML 的组件永远不会命中客户端 bundle。那是一个巨大的胜利。

现场的 Core Web Vitals

实验室基准是有用的，但现场数据更重要。基于来自我参与的网站的 CrUX（Chrome 用户体验报告）数据：

Next.js 网站：85% 通过所有三个 Core Web Vitals 阈值
Gatsby 网站：62% 通过所有三个（主要在 INP 和 TBT 上失败）

INP（交互到下一个绘制）指标是 Gatsby 真正苦恼的地方。更大的客户端 JavaScript bundle 意味着更多的主线程工作，这意味着交互更慢。Gatsby 的 hydration 模型需要在客户端处理整个页面的数据，而使用 RSC 的 Next.js 对服务器呈现的内容完全避免了这一点。

Next.js vs Gatsby 2026: 完整生产决策指南 - 架构

架构对比：RSC、App Router、SSG、ISR

渲染策略

Gatsby 围绕一个渲染策略构建：静态网站生成（SSG）。一切都在构建时生成。Gatsby 在 v4 中添加了 DSG（延迟静态生成），这是他们对 Next.js ISR 的回答，但它需要 Gatsby Cloud，并且从未像那样灵活。

Next.js 给你一切：

// 静态生成（等价于 Gatsby 的默认）
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

// ISR - 每 60 秒重新验证
export const revalidate = 60

// 或通过 API 路由按需重新验证
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { path } = await request.json()
  revalidatePath(path)
  return Response.json({ revalidated: true })
}

数据层问题

Gatsby 的 GraphQL 数据层很创新，但最终成为了一个负债。每个数据源都需要一个源插件。如果插件不存在或没有被维护，你就陷入了写一个的困境。构建时 GraphQL schema 很强大，但增加了显著的复杂性和构建时间。

Next.js 采用不同的方法：只是获取数据。使用任何你想要的东西——REST API、GraphQL 客户端、数据库查询、CMS SDK。没有框架强加的数据层。这既更简单又更灵活。

// Next.js - 从任何来源、任何方式获取数据
async function getProducts() {
  // 直接数据库查询
  const products = await prisma.product.findMany()
  
  // 或 REST API
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // 或无头 CMS SDK
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

对于使用无头 CMS 设置的团队——Contentful、Sanity、Storyblok，无论什么——Next.js 更容易集成。你不需要源插件。你只需调用 API。

服务器组件改变一切

我一直回到 RSC，因为它真正是自 hooks 以来 React 中最重要的架构转变。以下是为什么它对这个对比很重要：

在 Gatsby 中，你整个页面组件树都运送到客户端。即使一个组件只是呈现从 CMS 获取的博客文章标题列表，该组件的代码和数据都会被序列化并发送到浏览器以进行 hydration。

在使用 RSC 的 Next.js 中，相同的组件在服务器上运行，呈现 HTML，客户端永远看不到组件代码或原始数据。浏览器获得 HTML。仅此而已。

这意味着：

更小的 bundle（如上所示）
服务器端组件没有 hydration 不匹配 bug
你可以在组件中直接使用仅服务器代码（数据库查询、文件系统访问）
敏感数据（API 密钥、业务逻辑）保留在服务器上

开发者体验与生态系统

方面	Next.js 15	Gatsby 5
TypeScript 支持	第一类，自动生成的类型	不错，但某些插件类型缺失
热重新加载速度	~200ms（Turbopack）	1-3 秒（webpack）
构建时间（200 页）	~45 秒	~3-5 分钟
插件生态系统	npm 包（通用）	Gatsby 特定插件（停滞）
文档	积极维护	主要自 2023 年冻结
社区（Discord/GitHub）	非常活跃	近乎沉默
工作市场需求	高	快速下降
学习资源（2025-2026）	丰富	稀少

开发者体验差距已经大大扩大。使用 Turbopack 的 Next.js 给你近乎即时的热重新加载。Gatsby 的基于 webpack 的开发服务器相比之下感觉迟缓，特别是在更大的网站上。

构建时间值得特别提及。一个 500 页的 Gatsby 网站，进行繁重的图像处理，可能需要 15-20 分钟来构建。等效的 Next.js 网站，使用按需图像优化，在不到 2 分钟内构建，因为图像在请求时（然后被缓存）而非构建时进行处理。

总拥有成本

让我们谈论金钱。这是决策对业务利益相关者变得真实的地方。

托管成本

场景	Vercel 上的 Next.js	Netlify 上的 Gatsby
小网站（< 100 页，流量低）	$0-20/月	$0-19/月
中型网站（500 页，100k 访问/月）	$20-150/月	$19-99/月
大型网站（5000+ 页，1M+ 访问/月）	$150-500/月	$99-300/月*

*Gatsby 托管成本较低，因为它是纯静态——没有服务器计算。但你在构建时间和构建分钟上支付。

Next.js 也可以部署到其他平台：AWS（通过 SST 或 Amplify）、Cloudflare、自托管带 Node.js。Gatsby 的纯静态输出在理论上给了它更多的托管灵活性，但在实践中你失去了 ISR 和任何动态功能。

开发成本

这是真正的成本差异所在：

Gatsby 开发者费率：$120-180/小时（稀缺，遗留知识溢价）
Next.js 开发者费率：$100-200/小时（由于更大的人才库而范围更广）
迁移成本（中型 Gatsby 网站 → Next.js）：$15,000-50,000，取决于复杂性
持续维护（Gatsby）：更高，由于依赖管理、插件修复
持续维护（Next.js）：更低，更直接的升级路径

坚持 Gatsby 的隐藏成本是技术债务每天都在累积。你等待每一个月，迁移都会变得稍微困难一些，因为 Gatsby 生态继续恶化。

迁移路径：Gatsby 到 Next.js

我做过这个足够多次，有一个可重复的过程。以下是高级方法：

阶段 1：审计（1-2 周）

清点所有 Gatsby 插件及其 Next.js 等价物
将 GraphQL 数据层映射到直接 API 调用或 SDK 使用
识别 gatsby-node.js 逻辑（页面创建、schema 自定义）
编目所有动态功能（搜索、表单、认证）

阶段 2：基础（1-2 周）

使用 App Router 设置 Next.js 项目
配置 TypeScript、ESLint、Tailwind（或你的 CSS 方法）
直接设置 CMS 集成（不需要源插件）
使用 next/image 实现图像优化策略

阶段 3：页面迁移（2-6 周，取决于大小）

将页面模板转换为 Next.js 页面组件
将 gatsby-image / gatsby-plugin-image 替换为 next/image
将 <Link> 从 Gatsby 替换为 <Link> 从 Next.js（API 类似，幸运的是）
将 gatsby-node.js createPages 逻辑迁移到 generateStaticParams
将任何 gatsby-browser.js / gatsby-ssr.js 逻辑转换为布局组件

阶段 4：优化（1-2 周）

在适当的地方实现 ISR
为数据密集的部分添加服务器组件
从你的 CMS 设置按需重新验证 webhook
性能测试和优化

// 常见迁移模式：Gatsby 页面查询 → Next.js 数据获取

// 之前（Gatsby）
export const query = graphql`
  query BlogPostBySlug($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      body { raw }
      publishDate
      heroImage {
        gatsbyImageData(width: 1200)
      }
    }
  }
`

// 之后（Next.js App Router）
import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const entries = await client.getEntries({
    content_type: 'blogPost',
    'fields.slug': params.slug,
    limit: 1
  })
  
  const post = entries.items[0].fields
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Image
        src={`https:${post.heroImage.fields.file.url}`}
        width={1200}
        height={630}
        alt={post.title}
      />
      <RichText content={post.body} />
    </article>
  )
}

export const revalidate = 3600 // ISR: 每小时重新验证

迁移中最大的陷阱是图像处理。Gatsby 的图像管道确实很优秀——模糊向上占位符、响应式 srcset、延迟加载。好消息是 next/image 现在处理所有这些，但 API 是不同的，你需要更新每个图像引用。

何时 Next.js 不是答案

我想要公平这里。Next.js 不是每个项目的正确选择。

如果你对博客或文档网站需要绝对简单性，考虑 Astro。Astro 默认运送零 JavaScript，拥有出色的内容集合支持。对于纯粹内容驱动的网站，你不需要 React 的交互性，Astro 会以更少的复杂性给你更好的性能。

如果你在建立一个没有动态功能的简单静态网站，甚至 11ty 或 Hugo 可能更好地为你服务。不要给标记战争带来一个框架。

如果你被锁定在 Vue 或 Svelte 生态系统中，Nuxt 和 SvelteKit 是各自生态系统中的强大替代品。

但如果你需要 React，需要静态和动态内容的混合，需要很好的性能，需要一个未来会被积极维护多年的框架——Next.js 是 2026 年的明显选择。

结论

Next.js 赢了。这甚至不接近，自 2022 年以来一直都不接近。

Gatsby 在 React 生态系统中先驱了重要的想法：构建时优化、图像处理管道、统一数据层的概念。这些想法以不同的形式在现代框架中继续存在。但作为 2026 年的生产框架，Gatsby 是一个负债。

技术论证是压倒性的：

RSC 和 App Router 给了 Next.js 一个 Gatsby 无法匹配的架构优势
Bundle 大小小 40-60%
Core Web Vitals 分数一致更好
ISR 和 PPR 提供了 Gatsby 从未达到的渲染灵活性
生态系统繁荣 vs. 停滞

商业论证同样清楚：

更低的总拥有成本
更大的人才库
Vercel 的积极开发和支持
可预见未来的明确升级路径

如果你在开始一个新项目，使用 Next.js（如果你不需要 React，则使用 Astro）。如果你在生产环境运行 Gatsby，现在开始规划你的迁移。你等待越久，它变得越困难和越昂贵。

需要帮助进行该迁移？我们的团队已经做过很多次了。让我们交谈。

——Aaron Mitchell，Social Animal 高级 Headless 工程师

常见问题

Gatsby 在 2026 年完全死了吗？ Gatsby 还没有被 Netlify 正式宣布为生命终结，但实际上处于仅维护状态。自 2023 年末的 v5.13 以来没有重大发布，核心团队已经分散，插件生态正在恶化。对于新项目，它不是一个可行的选择。对于现有项目，你应该规划迁移。

从 Gatsby 迁移到 Next.js 需要多长时间？ 对于一个有 50-200 页的典型营销网站，预期 4-8 周的开发时间。有复杂数据关系、自定义插件或繁重 GraphQL 使用的更大网站可以需要 8-16 周。最大的变量是你使用的自定义 Gatsby 插件数量以及你有多深地集成 Gatsby 的 GraphQL 数据层。

Next.js 比 Gatsby 更难学吗？ App Router 和服务器组件确实有学习曲线，特别是如果你来自 Gatsby 的基于页面的模型。然而，心理模型最终更简单——你直接获取数据而不是经过 GraphQL 层，你编写在服务器或客户端上运行的组件。一旦他们超越初始 RSC 概念，大多数开发者发现 Next.js 更直观。

我可以在没有 Vercel 的情况下部署 Next.js 吗？ 绝对可以。Next.js 可以部署到 AWS（使用 SST、Amplify 或自定义设置）、Cloudflare Pages、DigitalOcean、Railway、Fly.io 或任何 Node.js 服务器上的自托管。Vercel 提供最优化的体验，但你没有被锁定。next start 命令运行一个标准的 Node.js 服务器。

Astro vs Next.js 对于静态网站？ 对于纯粹内容驱动的网站（博客、文档、交互性最少的营销页面），Astro 通常是更好的选择。它默认运送零 JavaScript 并支持多个 UI 框架。如果你需要 React 的交互性、动态路由、API 端点、认证或静态和动态内容的混合，Next.js 是更好的选择。

从 Gatsby 迁移到 Next.js 需要多少钱？ 开发成本通常从简单营销网站的 $15,000 范围到具有自定义数据管道、电子商务集成或国际化的复杂应用程序的 $50,000+。成本在很大程度上取决于需要替换的 Gatsby 插件数量、GraphQL 查询的复杂性，以及你是否想在迁移期间现代化架构（添加 ISR、服务器组件）。

Next.js 支持像 Gatsby 那样的静态导出吗？ 是的。在你的 next.config.js 中以 output: 'export' 运行 next build 生成一个完全静态的网站，可以在任何地方托管——S3、GitHub Pages、任何 CDN。你失去 ISR 和服务器端功能，但你获得与 Gatsby 相同的部署模型。一旦他们体验到 ISR 和服务器组件的好处，大多数团队发现他们不想要纯静态。

Gatsby Cloud 发生了什么？ Gatsby Cloud 在 Q1 2024 年关闭，大约在 Netlify 收购后一年。用户被迁移到 Netlify 的标准托管。这是一个重大打击，因为 Gatsby Cloud 提供了优化的构建、增量构建和预览功能，这些功能与 Gatsby 的架构紧密耦合。没有 Gatsby Cloud，在标准 CI/CD 平台上的构建时间明显更差。

Next.js vs Gatsby 2026: 为什么一个框架失败了及迁移成本

目录

2026 年 Gatsby 的现状

2026 年的 Next.js：实际改变了什么

性能基准：Lighthouse、Bundle 大小、Core Web Vitals

Lighthouse 分数（移动，5 次运行的中位数）

Bundle 大小对比

现场的 Core Web Vitals

架构对比：RSC、App Router、SSG、ISR

渲染策略

数据层问题

服务器组件改变一切

开发者体验与生态系统

总拥有成本

托管成本

开发成本

迁移路径：Gatsby 到 Next.js

阶段 1：审计（1-2 周）

阶段 2：基础（1-2 周）

阶段 3：页面迁移（2-6 周，取决于大小）

阶段 4：优化（1-2 周）

何时 Next.js 不是答案

结论

常见问题

Let's build
something together.

目录

2026 年 Gatsby 的现状

2026 年的 Next.js：实际改变了什么

性能基准：Lighthouse、Bundle 大小、Core Web Vitals

Lighthouse 分数（移动，5 次运行的中位数）

Bundle 大小对比

现场的 Core Web Vitals

架构对比：RSC、App Router、SSG、ISR

渲染策略

数据层问题

服务器组件改变一切

开发者体验与生态系统

总拥有成本

托管成本

开发成本

迁移路径：Gatsby 到 Next.js

阶段 1：审计（1-2 周）

阶段 2：基础（1-2 周）

阶段 3：页面迁移（2-6 周，取决于大小）

阶段 4：优化（1-2 周）

何时 Next.js 不是答案

结论

常见问题

Let's build something together.

Let's build
something together.