你在什么情况下应该选择使用 Next.js

点击上方 程序员成长指北，关注公众号
回复1，加入高级Node交流群

技术选型永远是最考验综合能力的。因为什么样的技术适合你当前所处的场景，你不仅要对某一个技术方案本身有足够的了解，你还要结合你的需求和团队的整体技术能力去进行综合判定。

但是很多人不明白，技术选型是对自己综合能力的严重考验，往往很容易会在舆论的裹挟之下，怀着一种边学习边研究边完成需求的心态，去贸然的决定选择使用一种技术方案，直接上到生产环境。

然后呢，就会造成很多怨恨和惨案。

所以在考虑什么时候用 Next.js 时，就算是我在某一篇文章中狂吹了他的爽点，但是，你最为读者，一定要谨记，这些爽点对你而言，一定一定只能作为参考，如果你决定自己在工作环境中选择使用 Next.js 来开发自己的项目，那么就一定要结合如下三个方面的东西综合考虑

• 1、 你们团队的需求是什么
• 2、 你们项目的应用场景是什么
• 3、 你们团队的整体开发能力如何

吹，我肯定会吹，因为站在我的角度，确实在使用过程中感受到了 Next.js 的成熟度和在用户体验上的极致追求，但是什么时候用在生产环境？你一定要慎重考虑。因为我不可能在每一篇文章里都强调应用场景，可能只是在之前的某一篇中明确了它们

所以呢，这篇文章，重新专门以 Next.js 的应用场景为主题，跟大家分享一下它的应用场景。

1

Next.js 能做什么？

这是我们首先要搞清楚的一个问题。Next.js 自称是一门全栈框架。因此，对于 Next.js 来说，他的视野是聚焦在一个完整项目，而不是仅仅只是前端项目。也就意味着，要用好 Next.js，你可能就不可避免的要跟服务端、数据库这种服务端概念打交道。

这也不可避免的造成了对开发者的技术综合能力有更高的要求。，因此对于前端开发而言，如果在服务端的技术储备存在短板的话，是可能会遇到比较难受的情况。你会觉得 Next.js 用起来可能并不是那么舒服。

特别是在项目部署这一块可能会遇到很大的不适应。

那么 Next.js 作为一门全栈框架，它能干什么呢？

✓

本文基于 Next.js 最新版本来探讨

一、他可以作为纯客户端框架来使用

Next.js 自带了属于自己的路由方案。如果你把 Next.js 当成纯客户端框架来运用，我们只需要在项目根节点的文件中，添加一个 use client 即可。

后续的所有的文件与组件都可以不需要额外添加了。从这一个角度来说，开发体验和其他的脚手架其实差别不大。不过由于现在使用 Vite 等工具，在偏中小型的项目中，开发时的编译速度非常快，因此开发体验更好，除此之外，还有更成熟、可控性更强完整的路由方案。

所以呢，如果你已经非常明确的敲定了自己的项目就是一门纯客户端项目，Next.js 是一个可以满足需求的选择，但不一定是一个最佳选择。

但是如果你非常喜欢 Next.js，又希望统一团队中的技术选型，那么在最新的版本中，使用 Next.js 来开发纯客户端项目其实也并不会有太差的开发体验。但是你一定要谨记一个点，那就是，只需要在项目文件的根节点，添加 use client 即可。在这个基础之上，如果不满足需求，其他的解决方案都可以进行魔改。

许多人认为开发体验差的主要原因是因为他不知道这个事情，错误的理解了 use client 的作用。

use client 的作用是作为组件树的边界来使用的。因此，在使用时，我们只需要添加合适的边界即可，而不是在每个客户端组件中添加它。

当然编译速度慢也是一个点，不过在新的版本中，Next.js 的底层脚手架 Turbopack 已经基于 rust 完成了重构，编译速度有了极大的提升，因此也可以作为一个选择。

二、可以作为纯服务端框架来使用

Next.js 的 API Routes 允许我们在应用中创建独立的服务端功能。因此，我们可以单纯的只使用 Next.js 构建一套独立的服务端 API。

import type { NextApiRequest, NextApiResponse } from 'next'
 
type ResponseData = {
  message: string
}
 
export default function handler(
  req: NextApiRequest,
  res: NextApiResponse<ResponseData>
) {
  res.status(200).json({ message: 'Hello from Next.js!' })
}

和纯粹的服务端解决方案（Nest.js）相比，Next.js 所提供的方案更加的简单与单薄，因此可能在应对一些业务逻辑非常复杂的场景时会存在很多短板。

但是在一些中小型的项目中，我们可以用它来处理一些简单的逻辑。不过相对于整个服务端解决方案而言，语言层面只是其中很小的一部分，在数据库、部署、性能、监控等方面我们还需要额外学习很多知识才能有底气说我可以很好的处理好他们。

因此，如果你将 Next.js 当成纯服务端框架来使用，那么还应该基于后端视角扩展其他更多的知识点。大多数情况下，我们也不会单独把 Next.js 当成纯服务端框架来使用。更多的是作为一个 BFF 层处理一些简单的二次逻辑。

现在是底子已经有了，未来的发展可以观望一下

三、可以作为服务端渲染的框架来使用

服务端渲染是 Next.js 最擅长的应用场景。

服务端渲染因为涉及的技术场景很复杂，必须要求开发者同时考虑服务端与客户端。但是如果拆开的话，就会变成两个项目，从开发体验的角度来说就不是很好。因此服务端渲染解决方案的探索持续了很多年。

开发方案经历了最开始的纯模板渲染 + jQuery，到后面的同构，到 Next.js RSC。发展到现在，Next.js 的 RSC 是处理服务端渲染场景最简单的解决方案。

和客户端渲染相比，由于服务端渲染把初始化的工作全部集中在服务端来做，因此服务端的压力远远高于客户端渲染的方案。

在这个基础之上，当用户访问的规模上来之后，要保证渲染性能就是一件非常考验技术能力的事情。RSC 根据场景的不同，在保留传统动态 SSR 特性的基础之上，提出了 SSG 与 ISR 来解决服务端的压力

除此之外，还预设了其他几种有效的缓存策略，进一步来缓解服务端压力。

所以，虽然 Next.js 在服务端渲染上非常的擅长，但是由于这个场景本身就是非常复杂的，要解决好这个问题，不仅要对场景的复杂度有一个比较深刻的认识，还需要对 Next.js 的对应的解决策略非常熟悉，才能做到对症下药。

四、他可以作为全栈框架来使用

一般情况下，专门用于服务端渲染的项目，基本上是不会与数据库打交道的，我们只需要通过接口请求其他服务提供的 api 获取数据即可。

Next.js 作为一门全栈框架，他提供了一些基础好用的能力，让我们可以在函数逻辑中，直接访问数据库。

这样，我们就可以把 Next.js 当成一门全栈框架来使用。

export async function getLikeCount(article: string) {
  const supabase = await createClient()
  const {data, error} = await supabase.from('next').select('*').eq('article', article)
  if (error) {
    console.error(error)
    return error
  }
  return data[0].like_count || 0
}

async function Index({ article = 'helox' }) {
  const res = await getLikeCount(article)

  return (
    <LikeButton article={article} like={res} />
  )
}

和 nest.js 相比，Next.js 访问数据库的方式更加的简单直白。他的逻辑与传统的函数组件逻辑有很大的相似之处。因此上手难度也会低很多。

如果从全栈的视角来看待这个方案的开发体验的话，他无疑是具备非常强大的竞争力的。但由于是考虑到这是一个全栈方案，因此他必定只能在整体架构中定位成应用层，所以在大型项目中能处理的逻辑也是有限的。

我们可以把一些轻量的、偏应用层的逻辑放到 Next.js 中来处理，能极大的降低前后端的沟通成本。

2

场景思考

✓

通常情况下，我会站在整个开发团队多个项目的角度去思考技术选型，这里我们从商用项目的角度去探讨。

第一个是需求层面。

如果你们团队的项目，对 SEO 有刚需。那么毫无疑问，你就必须选择一门服务端渲染的方案，因此可以把 Next.js 作为一个备选。这没有太多可探讨的空间。

如果你们团队的项目，对首屏快速直出有强烈的需求。而不是看到一个 Loading 组件之后再出现内容。

那么更高的要求，就必然会导致需要一门更复杂的方案来解决问题，这个时候，也应该把 Next.js 作为一个备选。因此在这个角度来说，纯后台管理系统，可以选择 Next.js 吗？当然可以。但是许多团队的需求不会这么变态，大多数后台管理系统在性能上的要求没有那么高。基本上处于一种：能用就行的状态。在这种情况下，选择 Next.js 就会带来更大的开发和维护成本，这是不划算的。

但也并不是说，没有团队对后台管理系统有性能要求。而是随着 B 端业务的越来越主流，许多团队对后台管理系统有性能要求目前已经变成了一种发展趋势。

这种发展趋势还来源于许多开发团队，长期以来对后台管理系统的性能重视程度非常低，因此有的项目出来的效果差得超乎想象，从而导致了这一点变成了客户多次要求的刚需。比如说，有的项目，页面 Loading 5 秒钟以上，内容还没有出来。这就很难受。

除此之外，C 端的项目往往对首屏快速直出有更高更直接的诉求。特别是一些内嵌到客户端的混合开发方案里、官网、文章博客等。

如果你们团队的项目，对更小的打包体积有强烈的诉求。那么可以把 Next.js 作为一个备选方案。Next.js 可以把一些只输出结果的三方工具库放到服务端或者构建时运行，从而减少客户端的运行时代码量。在部分项目中，打包体积可以明显减少。

如果你希望统一技术栈。从项目 Leader 的角度来说，在团队内部统一基础技术栈有非常大的好处，而不是有的项目用 React，有的项目用 Vue。由于 React 的生态相比与 Vue 而言更加的完善，因此如果你有这个诉求的话，我会建议你把 Next.js 作为一个备选。因为在开发网页应用、小程序应用、客户端应用、服务端应用都有成熟的生态，因此统一基础技术栈是有希望可以做到的。

✓

当然，如果你所负责的项目没有那复杂，就可以不把这一条作为考虑因素。

统一基础技术栈之后，能给团队的管理带来非常大的便利，包括更低的项目维护成本，更低的项目交接成本，更低的团队管理成本等等。

如果你对服务端熟悉。那么 Next.js 能够在你手上发挥出更加出色的表现。因此用 Next.js 会对开发者有更高的技术水平的要求，那么团队所能达到的技术状态也需要作为一个重要的考虑因素。否则强行使用会很容易遇到解决不掉的问题，从而极大的影响开发体验。

!

如果你对服务端不熟悉，那么可以依赖于 vercel 提供的便利，通过开发个人项目的方式来感受 Next.js 的魅力。因为如果对服务端不熟悉的话，那么要把一个全栈应用部署到自己的服务器上还要额外折腾的东西比较多。这对于普通的纯前端开发而言是一个不小的挑战。

3

总结

从结果上来说，Next.js 可以覆盖大多数网页开发的场景。但是它是否适合你，是否适合团队，则需要根据实际的情况去综合的考虑，然后做出选择。而不是贸然的将其应用在生产环境。

当然，按照我的判断，越来越多的团队，对首屏快速直出有更直接的要求，目前已经是一种发展趋势。因此很多团队不会仅仅限于要做 SEO 而选择 Next.js。Next.js 也在这方面做了很多优化考虑

我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。
   “分享、点赞、在看” 支持一波👍