Next.js vs Gatsby 2026：完整生产决策指南
如果你仍在生产环境中运行 Gatsby，你需要一个迁移计划。如果你正在为一个新项目选择框架，答案很直接但也有细微差别。让我为你详细讲解。
目录
- 2026 年 Gatsby 的现状
- 2026 年 Next.js：实际改变了什么
- 性能基准测试：Lighthouse、Bundle 大小、Core Web Vitals
- 架构对比：RSC、App Router、SSG、ISR
- 开发者体验和生态系统
- 总体拥有成本
- 迁移路径：Gatsby 到 Next.js
- Next.js 不是答案的情况
- 结论
- 常见问题
2026 年 Gatsby 的现状
我们直言不讳吧。实际上，Gatsby 已经被放弃了。
Netlify 在 2023 年 2 月收购了 Gatsby Inc。承诺是继续开发并与 Netlify 的平台集成。但实际发生的是一个缓慢的停止。最后一个有意义的 Gatsby 发布版本（v5.13）在 2023 年末发布。GitHub 仓库自 2024 年中期以来几乎没有维护提交。关键维护人员离开了。插件生态系统已经停滞——许多流行的插件已经超过 18 个月没有更新。
以下是重要的时间表：
| 日期 | 事件 |
|---|---|
| 2023 年 2 月 | Netlify 收购 Gatsby Inc. |
| 2023 年 Q3 | Gatsby v5.13 发布（最后一个重要版本） |
| 2024 年 Q1 | Gatsby Cloud 正式关闭 |
| 2024 年 Q2 | 核心团队成员离开 Netlify |
| 2024 年 Q4 | npm 周下载量下降到 15 万以下（之前峰值为 80 万+ ） |
| 2025 年 Q1 | Netlify 从主导航中删除 Gatsby 特定文档 |
| 2026 | 没有 v6 版本、没有路线图、实际上处于维护模式 |
npm 下载数据讲述了整个故事。2021 年的峰值，Gatsby 每周拉取超过 80 万次下载。截至 2026 年初，它徘徊在 10 万左右——而且大多数是来自现有的 CI/CD 管道，而不是新项目。
我说这些不是为了贬低 Gatsby。它确实推动了 React 生态系统向前发展。build 时间数据层配合 GraphQL 的想法、build 时间的图像优化、插件架构——这些都是真正的创新。但当 Next.js 在 2020 年末发布 ISR 时，这个框架在技术上失败了，当 Netlify 停止投资它时，它在商业上失败了。
如果你现在在生产环境中运行 Gatsby，你最大的风险是：
- 未维护依赖中的安全漏洞
- Node.js 版本不兼容随着生态系统向前发展
- 插件腐烂——第三方插件中断且没有上游修复
- 招聘困难——开发者不想在 2026 年的简历上写 Gatsby
2026 年 Next.js：实际改变了什么
Next.js 15 在 2024 年末发布，整个 2025 年的迭代版本已经巩固了 App Router 作为主要开发模型。情况如下：
React Server Components (RSC) 现在是默认的。当你在 App Router 中创建一个组件时，它是一个 Server Component，除非你显式添加 'use client'。这不仅仅是一个语法变化——它根本改变了我们对数据获取和组件架构的思考方式。
Partial Prerendering (PPR) 在 Next.js 15.1 中达到稳定。这是一个即使 Gatsby 仍在积极开发中也会杀死 Gatsby 的功能。PPR 让你立即提供一个静态外壳，同时流式传输动态内容。你获得了 SSG 的速度和 SSR 的灵活性。这是两全其美，这是 Gatsby 的架构永远无法支持的。
Server Actions 已经成熟了很多。表单处理、mutations、重新验证——这些模式现在已经确立，它们已经取代了我们过去写的大量 API 路由样板代码。
// Next.js 15 - Server Action 示例
// 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 年初开始对生产构建稳定）。与 webpack 相比，next dev 的冷启动时间下降了 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 运行时和数据层。Next.js 配合 App Router 和 RSC 发送给客户端的 JavaScript 明显更少，因为 Server Components 根本不会对客户端 bundle 产生影响。
| 指标 | Next.js 15（App Router） | Gatsby 5.13 |
|---|---|---|
| 首次加载 JS | 87 KB（gzipped） | 210 KB（gzipped） |
| 路由 JS（平均） | 12 KB | 45 KB |
| 总 JS（50 页网站） | 145 KB | 380 KB |
| 图像优化 | 内置（按需） | Build 时间（gatsby-plugin-image） |
| 字体优化 | 内置（next/font） | 手动或插件 |
Bundle 大小差异主要归功于 RSC。在典型的 Gatsby 网站中，每个组件都会发送到客户端，即使它只呈现静态内容。在使用 Server Components 的 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 模型需要在客户端处理整个页面的数据，而 Next.js 配合 RSC 完全避免了这一点，用于服务器呈现的内容。
架构对比：RSC、App Router、SSG、ISR
渲染策略
Gatsby 是围绕一种渲染策略构建的：静态站点生成（SSG）。一切都在 build 时进行构建。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 数据层很有创新性，但最终成为了一个负担。每个数据源都需要一个源插件。如果插件不存在或没有被维护，你就被困在自己编写一个。Build 时 GraphQL schema 是强大的，但增加了重大的复杂性和 build 时间。
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 }
})
// 或 headless CMS SDK
const entries = await contentful.getEntries({ content_type: 'product' })
return products
}
对于使用 headless CMS 设置的团队——Contentful、Sanity、Storyblok，无论什么——Next.js 集成起来简单得多。你不需要源插件。你只需调用 API。我们在我们的 headless CMS 开发 工作中深入介绍了这一点。
Server Components 改变了一切
我一直在回到 RSC，因为它确实是 React 自 hooks 以来最重要的架构转变。以下是它对这个比较的重要之处：
在 Gatsby 中，整个页面组件树都会发送到客户端。即使一个组件只是呈现从 CMS 获取的博客文章标题列表，该组件的代码及其数据也会被序列化并发送到浏览器进行 hydration。
在使用 RSC 的 Next.js 中，同一个组件在服务器上运行、呈现 HTML，客户端永远看不到组件代码或原始数据。浏览器获得 HTML。就这样。
这意味着：
- 更小的 bundle（如上所示）
- 不会出现服务器专用组件的 hydration 不匹配 bug
- 你可以直接在组件中使用仅服务器代码（数据库查询、文件系统访问）
- 敏感数据（API 密钥、业务逻辑）保留在服务器上
开发者体验和生态系统
| 方面 | Next.js 15 | Gatsby 5 |
|---|---|---|
| TypeScript 支持 | 一流、自动生成的类型 | 不错，但某些插件类型缺失 |
| 热重新加载速度 | ~200ms（Turbopack） | 1-3 秒（webpack） |
| Build 时间（200 个页面） | ~45 秒 | ~3-5 分钟 |
| 插件生态系统 | npm 包（通用） | Gatsby 特定插件（停滞） |
| 文档 | 积极维护 | 主要自 2023 年冻结 |
| 社区（Discord/GitHub） | 非常活跃 | 几乎沉寂 |
| 就业市场需求 | 高 | 快速下降 |
| 学习资源（2025-2026） | 丰富 | 稀缺 |
开发者体验差距已经大幅扩大。使用 Turbopack 的 Next.js 提供了近乎即时的热重新加载。相比之下，Gatsby 的 webpack 开发服务器感觉缓慢，特别是在更大的网站上。
Build 时间值得特别提及。一个有 500 个页面的 Gatsby 网站，带有重型图像处理，build 时间可能需要 15-20 分钟。等效的 Next.js 网站在不到 2 分钟内构建，因为图像在请求时（然后缓存）进行处理，而不是在 build 时进行处理。
我们的 Next.js 开发团队 在数十个项目中看到了这种情况。Build 时间直接影响开发者的生产力和 CI/CD 成本。
总体拥有成本
让我们谈论金钱。这是决定对业务利益相关者变得真实的地方。
托管成本
| 场景 | Vercel 上的 Next.js | Netlify 上的 Gatsby |
|---|---|---|
| 小网站（< 100 个页面、低流量） | $0-20/mo | $0-19/mo |
| 中等网站（500 个页面、10 万次访问/月） | $20-150/mo | $19-99/mo |
| 大型网站（5000+ 个页面、100 万+ 次访问/月） | $150-500/mo | $99-300/mo* |
*Gatsby 托管成本更低，因为它是纯静态的——没有服务器计算。但你在 build 时间和 build 分钟上支付。
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 - 将 Gatsby 中的
<Link>替换为 Next.js 中的<Link>（API 类似，幸运的是） - 迁移
gatsby-node.jscreatePages逻辑到generateStaticParams - 将任何
gatsby-browser.js/gatsby-ssr.js逻辑转换为布局组件
第 4 阶段：优化（1-2 周）
- 在适当的地方实现 ISR
- 为数据密集的部分添加 Server Components
- 从你的 CMS 设置按需重新验证 webhooks
- 性能测试和优化
// 常见迁移模式：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 的图像管道确实非常出色——模糊占位符、响应式 srcsets、延迟加载。好消息是 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 生态系统中开创了重要的想法：build 时间优化、图像处理管道、统一数据层的概念。这些想法以不同的形式在现代框架中继续存在。但作为 2026 年的生产框架，Gatsby 是一个负债。
技术论证是压倒性的：
- RSC 和 App Router 给 Next.js 一个 Gatsby 无法匹配的架构优势
- Bundle 大小小 40-60%
- Core Web Vitals 分数始终更好
- ISR 和 PPR 提供 Gatsby 从未实现的渲染灵活性
- 生态系统蓬勃发展与停滞
业务论证同样清晰：
- 更低的总体拥有成本
- 更大的人才库
- 来自 Vercel 的积极开发和支持
- 清晰的可预见未来的升级路径
如果你正在启动一个新项目，使用 Next.js（或 Astro，如果你不需要 React）。如果你在生产环境中运行 Gatsby，现在开始计划你的迁移。你等待的越久，它变得越难、越昂贵。
需要帮助迁移？我们的团队已经做过很多次了。让我们谈谈。
— Aaron Mitchell，Social Animal 高级 Headless 工程师
常见问题
2026 年 Gatsby 完全死了吗？ Gatsby 还没有被 Netlify 正式宣布生命周期结束，但实际上处于仅维护状态。自 2023 年末的 v5.13 以来没有重要版本、核心团队已经散开、插件生态系统正在恶化。对于新项目，它不是一个可行的选择。对于现有项目，你应该计划迁移。
从 Gatsby 迁移到 Next.js 需要多长时间？ 对于典型的营销网站，50-200 个页面，预计 4-8 周的开发时间。具有复杂数据关系、自定义插件或深度 GraphQL 集成的较大网站可能需要 8-16 周。最大的变量是你使用的自定义 Gatsby 插件的数量以及你与 Gatsby GraphQL 数据层集成的深度。
Next.js 比 Gatsby 更难学吗？ App Router 和 Server Components 确实有一个学习曲线，特别是如果你来自 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 与 Next.js 对比静态网站？ 对于纯内容驱动的网站（博客、文档、很少交互的营销页面），Astro 通常是更好的选择。它默认不发布任何 JavaScript，并支持多个 UI 框架。如果你需要 React 的交互性、动态路由、API 端点、身份验证，或静态和动态内容的混合，Next.js 是更好的选择。我们两者都支持——查看我们的 Astro 开发 页面以了解何时推荐它。
从 Gatsby 迁移到 Next.js 需要多少成本？ 开发成本通常范围从简单营销网站的 $15,000 到具有自定义数据管道、电子商务集成或国际化的复杂应用程序的 $50,000+。成本主要取决于需要替换的 Gatsby 插件数量、GraphQL 查询的复杂性，以及在迁移过程中是否要现代化架构（添加 ISR、Server Components）。
Next.js 支持像 Gatsby 那样的静态导出吗？
是的。在你的 next.config.js 中运行 next build 并设置 output: 'export' 会生成一个完全静态的网站，可以在任何地方托管——S3、GitHub Pages、任何 CDN。你失去了 ISR 和服务器端功能，但你获得了与 Gatsby 相同的部署模型。大多数团队发现一旦他们体验到 ISR 和 Server Components 的好处，他们就不想要纯静态。
Gatsby Cloud 发生了什么？ Gatsby Cloud 在 2024 年 Q1 关闭，大约在 Netlify 收购后一年。用户被迁移到 Netlify 的标准托管。这是一个重大打击，因为 Gatsby Cloud 提供了优化的构建、增量构建和预览功能，这些都与 Gatsby 的架构紧密耦合。没有 Gatsby Cloud，标准 CI/CD 平台上的 build 时间明显更糟。