什么是Next.js
如果你在考虑用 React 做技术栈来构建出海产品,你大概率会听到一个名字——Next.js。它是目前 React 生态中使用最广泛的框架,几乎成了「用 React 做项目」的默认选择。但 Next.js 到底是什么?它和纯 React 有什么区别?为什么出海产品尤其推荐它?本文会把这些问题讲清楚。
Next.js 是什么
Next.js 是一个基于 React 的全栈 Web 开发框架,由 Vercel 公司开发并维护,于 2016 年开源发布。它的定位很简单:在 React 的基础上,帮你处理那些「自己做很麻烦」的事情——路由配置、服务端渲染、静态生成、API 接口、图片优化、国际化路由等等。
用一个比喻来说:React 是一组乐高积木,你可以用它搭建任何东西,但你需要自己决定怎么拼、怎么固定、怎么展示;Next.js 则是一套带说明书的乐高套装,它告诉你推荐的拼法,并且帮你把底座、展示架和灯光都配好了。
从技术角度看,Next.js 在 React 之上提供了这几层能力:
- 框架层:文件系统路由、 layouts、loading 状态、错误处理等约定式结构
- 渲染层:支持 SSR、SSG、ISR、CSR 多种渲染策略,按页面粒度自由切换
- 服务端层:内置 API Routes(Route Handlers),可以直接在服务端写接口逻辑
- 优化层:自动代码分割、图片懒加载与格式转换、字体优化、脚本按需加载
这些能力让开发者不需要从零搭建工程化体系,就能产出性能优秀、SEO 友好的生产级应用。
核心特性详解
1. 多种渲染策略:SSR、SSG、ISR
Next.js 最核心的能力之一,就是让你为不同页面选择不同的渲染方式。这是纯 React(客户端渲染,CSR)做不到的。
SSR(Server-Side Rendering,服务端渲染):每次用户请求页面时,服务器实时渲染 HTML 并返回。适合内容频繁变化的页面,比如用户个人主页、实时数据看板。优点是内容始终是最新的,缺点是服务器需要处理每次请求,成本较高。
SSG(Static Site Generation,静态站点生成):在构建时(pnpm build)预先生成所有页面的 HTML。适合内容不常变化的页面,比如博客文章、产品介绍页、帮助中心。优点是速度极快、CDN 友好,缺点是内容更新需要重新构建。
ISR(Incremental Static Regeneration,增量静态再生):SSG 的进化版。页面在构建时预生成,但可以在运行时按需更新——设置一个 revalidate 时间(比如 60 秒),过期后下一次请求会触发后台重新生成。适合产品列表、价格页面这种「偶尔更新但不需要每次实时」的场景。ISR 是 Next.js 的独创特性,在出海电商和内容站中非常实用。
CSR(Client-Side Rendering,客户端渲染):和纯 React 一样,浏览器下载 JavaScript 后再渲染页面。适合登录后的仪表盘、编辑器等不需要 SEO 的交互密集页面。
在 Next.js 的 App Router 中,你可以通过 export const dynamic 和 export const revalidate 这些路由配置来逐页指定渲染策略,非常灵活。
2. 文件系统路由
Next.js 用文件和目录结构来定义路由,不需要手动配置路由表。这是它和传统 React 项目的一个显著区别。
在 App Router 模式下(Next.js 13+ 引入),路由规则如下:
app/page.tsx→ 对应网站根路径/app/about/page.tsx→ 对应/aboutapp/blog/[slug]/page.tsx→ 对应/blog/任意slug(动态路由)app/(marketing)/pricing/page.tsx→ 对应/pricing,(marketing)是路由分组,不影响 URLapp/[locale]/page.tsx→ 对应/en、/zh等(国际化常用模式)
这种约定式路由带来两个好处:第一,新人看到目录结构就知道网站有哪些页面;第二,代码分割是自动的——每个页面只加载自己需要的代码,不会因为路由变多而拖慢首屏。
3. API Routes(Route Handlers)
Next.js 不仅是前端框架,它还自带服务端能力。你可以在 app/api/ 目录下创建文件来定义 API 接口:
// app/api/hello/route.ts
export async function GET() {
return Response.json({ message: 'Hello from server' })
}这些 API 路由运行在服务端(Node.js 或 Edge Runtime),可以直接访问数据库、调用第三方服务、处理鉴权逻辑。对于出海产品来说,这意味着你可以在同一个项目中同时完成前端页面和轻量级后端接口,不需要额外搭建一个独立的 Express 或 Koa 服务。
当然,如果你的后端逻辑很复杂(比如涉及消息队列、定时任务、复杂的数据库迁移),仍然建议使用独立的后端服务。API Routes 更适合 BFF(Backend for Frontend)层、Webhook 处理、简单 CRUD 这类场景。
4. App Router 与 React Server Components
从 Next.js 13 开始引入的 App Router 是一个重要里程碑。它基于 React Server Components(RSC)构建,组件默认在服务端执行,不会把代码发送到客户端。
这意味着你可以在组件里直接写 async/await 来获取数据:
// app/products/page.tsx — 这是一个 Server Component
export default async function ProductsPage() {
const products = await fetch('https://api.example.com/products').then(r => r.json())
return (
<ul>
{products.map(p => <li key={p.id}>{p.name}</li>)}
</ul>
)
}这段代码在服务端执行,客户端收到的只是渲染好的 HTML,不包含数据获取逻辑。好处是:减少客户端 JavaScript 体积、避免数据获取的水合问题(waterfall)、天然对 SEO 友好。
需要交互的组件(按钮、表单、状态管理)仍然可以使用 'use client' 指令标记为客户端组件,两者可以在同一个页面中混合使用。
5. 内置优化能力
Next.js 在性能优化方面做了大量开箱即用的工作:
next/image:自动图片懒加载、根据设备生成合适尺寸、支持 WebP/AVIF 格式转换,对出海产品的多地区 CDN 分发非常重要next/font:Google Fonts 自动优化,消除布局偏移(CLS),支持自托管字体- 自动代码分割:每个页面只加载必要的 JS,不需要手动配置
React.lazy - 脚本优化:
next/script支持strategy="lazyOnload"等策略,控制第三方脚本(Google Analytics、Facebook Pixel)的加载时机
为什么出海产品推荐 Next.js
出海产品和国内产品有一个关键区别:你面对的用户分布在世界各地,网络环境差异大,搜索引擎以 Google 为主,多语言 SEO 是核心流量来源。这些需求恰好是 Next.js 的强项。
SEO 友好。Google 虽然能执行 JavaScript,但客户端渲染的页面在抓取效率和索引质量上仍然不如服务端渲染的页面。Next.js 的 SSR 和 SSG 模式能直接返回完整 HTML,让搜索引擎「一眼看到」所有内容。对于出海产品来说,这意味着更好的关键词排名、更多的自然流量。
多语言国际化支持。Next.js 原生支持国际化路由配置,配合 next-intl 或框架内置的 i18n 能力,你可以轻松实现 /en/products、/zh/products、/ja/products 这样的多语言 URL 结构。每种语言版本都是独立的 URL,Google 可以分别索引,再配合 hreflang 标签告诉搜索引擎「这个页面是给哪个语言用户看的」。有实践表明,搭配国际化的 Next.js 方案能为出海产品带来「事半功倍」的 SEO 效果。
全球部署简单。Next.js 可以部署到 Vercel 平台,一键推送、全球 CDN 自动分发。Vercel 在全球有数十个边缘节点,用户无论在美国、欧洲还是东南亚,都能快速加载页面。对于资源有限的出海团队来说,这种「零运维」的部署方式极大降低了基础设施成本。
生态丰富。Next.js 的社区生态在 React 框架中是最成熟的。你需要的功能——CMS 集成、支付对接、分析埋点、A/B 测试、多语言方案——几乎都有现成的库或最佳实践。这缩短了开发周期,对快速迭代的出海产品来说至关重要。
灵活的渲染策略。出海产品通常有多种页面类型:营销首页需要 SSG 保证加载速度和 SEO,商品列表需要 ISR 保持内容新鲜度,用户中心需要 CSR 处理复杂交互。Next.js 允许你在同一个项目中按需选择,不需要为了迁就框架而牺牲用户体验。
Next.js vs 纯 React vs 其他框架
选技术栈不能只看「谁更好」,而要看「谁更适合你的场景」。下面通过几个维度做对比。
对比表一:Next.js vs React vs Gatsby
| 维度 | Next.js | React | Gatsby |
|---|---|---|---|
| 定位 | 全栈框架 | UI 库 | 静态站点生成器 |
| 渲染方式 | SSR / SSG / ISR / CSR | 仅 CSR(需自行实现 SSR) | 主要 SSG |
| 路由方式 | 文件系统路由(约定式) | 需手动配置(React Router 等) | 文件系统路由 |
| 数据获取 | 服务端/客户端均可,灵活选择 | 仅客户端(需自建后端) | GraphQL 为主 |
| API 能力 | 内置 Route Handlers | 无(需独立后端) | 有 Serverless Functions |
| 社区活跃度 | 非常高(GitHub 130k+ stars) | 最高(核心库) | 较低,维护模式 |
| 适合场景 | 全栈应用、电商、SaaS、内容站 | 单页应用、后台管理系统 | 博客、文档站(逐渐被替代) |
Gatsby 在 2020 年前后很流行,但近年发展放缓,社区和生态正在被 Next.js 和 Astro 分流。新项目一般不推荐选 Gatsby。
对比表二:SSR / SSG / ISR / CSR 对比
| 渲染方式 | 执行时机 | HTML 生成位置 | 首屏速度 | SEO | 适用场景 |
|---|---|---|---|---|---|
| CSR(客户端渲染) | 用户访问时,浏览器执行 JS | 浏览器 | 较慢 | 较弱 | 登录后页面、仪表盘、编辑器 |
| SSR(服务端渲染) | 用户访问时,服务器实时渲染 | 服务器 | 快 | 好 | 用户个人主页、搜索结果页 |
| SSG(静态生成) | 构建时预生成 | 构建时 / CDN | 最快 | 最好 | 博客、帮助文档、产品介绍 |
| ISR(增量静态再生) | 构建时预生成 + 运行时按需更新 | 构建时 / CDN | 快 | 好 | 商品列表、新闻列表、价格页 |
对比表三:Next.js 核心特性一览
| 特性 | 说明 | 出海价值 |
|---|---|---|
| App Router | 基于 React Server Components 的路由系统 | 减少客户端 JS 体积,提升全球加载速度 |
| 文件系统路由 | 目录结构即路由,自动代码分割 | 降低维护成本,新人上手快 |
| API Routes | 内置服务端接口能力 | 实现 BFF 层,减少独立后端依赖 |
next/image | 自动图片优化、懒加载、格式转换 | 全球 CDN 图片分发,提升 Core Web Vitals |
next/font | 字体自动优化,消除布局偏移 | 多语言字体支持,改善用户体验 |
| 国际化路由 | 原生支持多语言 URL 结构 | 每种语言独立 SEO,多区域流量获取 |
| Middleware | 边缘中间件,在 CDN 节点执行逻辑 | 鉴权、A/B 测试、地区重定向,低延迟 |
| Streaming | 渐进式渲染,先返回页面骨架 | 用户更早看到内容,改善感知性能 |
对比表四:框架适合场景对照
| 场景 | 推荐框架 | 原因 |
|---|---|---|
| 出海 SaaS 产品(含营销站 + 后台) | Next.js | SSR 做营销站 SEO,CSR 做后台交互,一套搞定 |
| 出海电商平台 | Next.js | ISR 保证商品页实时更新,SSG 保证加载速度 |
| 纯内部管理系统(无需 SEO) | React + Vite | 轻量快速,不需要框架 overhead |
| 个人博客 / 文档站 | Astro 或 Next.js | Astro 更轻量,Next.js 生态更丰富 |
| 纯静态内容站 | Astro 或 Next.js SSG | Astro 构建更快,JS 体积更小 |
| 需要重度 GraphQL 的静态站 | Gatsby(已有项目) | Gatsby 的 GraphQL 数据层适合内容聚合 |
真实案例
案例一:TikTok — 全球短视频平台的 Web 端
TikTok 的 Web 端使用了 Next.js 来构建。作为一个面向全球的短视频平台,TikTok 需要处理多语言、多地区的页面渲染,同时保证全球用户的访问速度。Next.js 的服务端渲染能力让 TikTok 的 Web 页面在搜索引擎中有良好的索引表现,而 ISR 和 CDN 分发策略则保证了不同地区用户都能快速加载内容。
案例二:Notion — 产品官网与落地页
Notion 的产品官网和营销落地页使用 Next.js 构建。Notion 作为一个全球化 SaaS 产品,官网的 SEO 表现直接影响获客。Next.js 的 SSG 模式让 Notion 的落地页拥有极快的加载速度,同时 SSR 能力支撑了需要动态内容的页面(如多语言切换、用户状态判断)。清晰的 URL 结构也让 Google 能高效索引各语言版本的页面。
案例三:Nike — 部分电商体验
Nike 在其部分电商产品页面中采用了 Next.js。电商场景对页面加载速度和 SEO 有极高要求——商品页需要在 Google 搜索中获得好的排名,同时需要在全球范围内快速呈现高清商品图。Next.js 的 next/image 图片优化能力和 ISR 模式(商品信息更新后无需重新构建全站)正好满足这些需求。
Next.js 请求处理流程
下面用一张 Mermaid 流程图展示 Next.js 处理一个页面请求的完整过程:
这个流程说明了 Next.js 的核心价值:它帮你在正确的时机、正确的地点,做正确的渲染。用户看到的速度快,搜索引擎抓取得到内容,开发者不需要手动处理这些复杂逻辑。
检查清单:你是否应该用 Next.js
在决定技术选型之前,可以用以下清单做一个快速判断:
- 你的产品是否需要被 Google 等搜索引擎收录?(需要 → Next.js 的 SSR/SSG 有优势)
- 你的产品是否需要支持多语言、多地区?(需要 → Next.js 的国际化路由和 Middleware 很适合)
- 你的产品是否面向全球用户?(是 → Next.js + Vercel 的全球 CDN 分发是低成本方案)
- 你的团队是否熟悉 React?(是 → Next.js 学习曲线平缓,React 经验可以直接复用)
- 你是否需要同时处理前端页面和轻量级后端接口?(需要 → API Routes 可以省去独立后端项目)
- 你的产品是否有多种页面类型(营销页、商品页、用户中心)?(有 → Next.js 的混合渲染策略能按页面选择最优方案)
- 你希望快速部署、减少运维负担?(是 → Vercel 一键部署,不需要自己管理服务器)
- 你的项目是纯内部系统,完全不需要 SEO?(是 → React + Vite 可能更轻量合适)
- 你的项目是非常简单的静态页面(1-3 页)?(是 → Astro 或直接手写 HTML 可能更简单)
- 你是否需要大量的 GraphQL 数据聚合?(是且项目已启动 → Gatsby 可能有优势;新项目 → Next.js 也支持 GraphQL)
- 你的团队是否需要丰富的第三方生态?(需要 → Next.js 的社区和插件生态最成熟)
- 你是否关注 Core Web Vitals 评分?(是 → Next.js 内置的图片优化、字体优化、代码分割直接影响这些指标)
如果你对大多数问题的回答都指向 Next.js,那它很可能就是你的正确选择。
小结
Next.js 不是一个「必须用」的框架,但在当前(2025-2026 年)的技术环境下,它确实是出海产品最稳妥的选择之一。它在 SEO、国际化、全球部署、开发效率这几个出海核心需求上,提供了目前最成熟的综合方案。
对于初学者,建议的学习路径是:先掌握 React 基础 → 学习 Next.js App Router → 理解 SSR/SSG/ISR 的区别和适用场景 → 动手搭建一个多语言的出海落地页。这个过程不需要很长时间,但会让你对出海技术栈有一个扎实的起点。
参考资料
- Next.js 官方文档 — 框架的权威参考资料,涵盖 App Router、渲染策略、API Routes 等核心概念
- React Foundations: About React and Next.js — Next.js 官方教程中关于 React 与 Next.js 关系的基础讲解
- Next.js Official Showcase — 官方展示页面,收录了大量使用 Next.js 构建的真实产品案例
- Next.js 国际化最佳实践——SEO 流量高的离谱 — 知乎专栏文章,讲解 Next.js 搭配国际化对出海产品 SEO 的提升效果
- Understanding SSR, SSG, ISR, and CSR in Next.js App Router — 详细解析 App Router 下各种渲染策略的实现方式和区别
- Next.js vs. Gatsby in 2025: A Full Comparison — Next.js 和 Gatsby 的全面对比分析
- Next.js vs Gatsby vs Remix: Full Comparison for 2026 — 三大 React 框架的横向对比,涵盖架构、性能、SEO 和开发者体验
- 如何优化多语言 Next.js 应用的 SEO — 多语言 Next.js 应用的 SEO 优化指南,包含 hreflang 和站点地图配置